Skip to contentSkip to conversation

netlink bug?

KJ Jaco Kroon 2 participants 3 messages Apr 25, 2007 Kernel janitors

lore
Share & tools
lore

Jaco Kroon

author
#0 lore raw

Hi guys,

I've got a piece of code that seems to reliably cause the kernel to panic, looks like a problem somewhere down the netlink core...

I've been trying to use NETLINK_FIB_LOOKUP but so far the closest I've come to success was a kernel crash, a slightly stripped down version of the code that first crashed it attached. If somebody else can confirm this it would be appreciated, also, any pointers on what I'm doing wrong that triggers the behaviour to begin with would be appreciated, thanks.

I'm currently on kernel version 2.6.19.2, so this may have been fixed in the meantime. Note that I don't need to run the code as root in order to trigger the crash.

Jaco

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <memory.h>
#include <unistd.h>
#include <sys/socket.h>
#include <linux/netlink.h>

/* stolen from kernel source ... could be a problem here ... */

struct fib_result_nl {
	uint32_t        fl_addr;   /* To be looked up*/
	uint32_t        fl_fwmark;
	unsigned char   fl_tos;
	unsigned char   fl_scope;
	unsigned char   tb_id_in;

	unsigned char   tb_id;      /* Results */
	unsigned char   prefixlen;
	unsigned char   nh_sel;
	unsigned char   type;
	unsigned char   scope;
	int             err;
};
struct msg {
	struct nlmsghdr nh;
	struct fib_result_nl frn;
};

int main()

{
	struct msg msg;
	struct sockaddr_nl sa;
	int fd;

	memset(&sa, 0, sizeof(sa));
	sa.nl_family = AF_NETLINK;
	sa.nl_pid = getpid();

	assert((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_FIB_LOOKUP)) > 0);
	assert(bind(fd, (struct sockaddr*)&sa, sizeof(sa)) == 0);

	sa.nl_pid = 0;
	memset(&msg, 0, sizeof(msg));
	msg.nh.nlmsg_len = sizeof(msg);
	msg.nh.nlmsg_flags = NLMSG_DONE;

	assert(sendto(fd, &msg, sizeof(msg), 0, (void*)&sa, sizeof(sa)) > 0);

	return 0;
}

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

#1 lore raw
Quoted 11 lines · Jaco Kroon

Hi guys,

I've got a piece of code that seems to reliably cause the kernel to panic, looks like a problem somewhere down the netlink core...

I've been trying to use NETLINK_FIB_LOOKUP but so far the closest I've come to success was a kernel crash, a slightly stripped down version of the code that first crashed it attached. If somebody else can confirm this it would be appreciated, also, any pointers on what I'm doing wrong that triggers the behaviour to begin with would be appreciated, thanks.

Quoted 3 lines

I'm currently on kernel version 2.6.19.2, so this may have been fixed in the meantime. Note that I don't need to run the code as root in order to trigger the crash.

Next time, if you find a kernel issue like this, could you just forward this to the [email protected] mail alias? This turned out to be a real kernel issue, and now 2.6.20.8 is released with a fix for this problem.

I still think there's a bug in your userspace program, but the kernel shouldn't die anymore at least :)

thanks,

greg k-h
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

author
#2 lore raw
In reply to Jaco Kroon
Quoted 16 lines · Greg KH
Quoted 11 lines · Jaco Kroon

Hi guys,

I've got a piece of code that seems to reliably cause the kernel to panic, looks like a problem somewhere down the netlink core...

I've been trying to use NETLINK_FIB_LOOKUP but so far the closest I've come to success was a kernel crash, a slightly stripped down version of the code that first crashed it attached. If somebody else can confirm this it would be appreciated, also, any pointers on what I'm doing wrong that triggers the behaviour to begin with would be appreciated, thanks.

Quoted 3 lines

I'm currently on kernel version 2.6.19.2, so this may have been fixed in the meantime. Note that I don't need to run the code as root in order to trigger the crash.

Quoted 7 lines

Next time, if you find a kernel issue like this, could you just forward this to the [email protected] mail alias? This turned out to be a real kernel issue, and now 2.6.20.8 is released with a fix for this problem.

I still think there's a bug in your userspace program, but the kernel shouldn't die anymore at least :)

Trust me, I know there is a bug in my userspace app, wasn't aware of the [email protected] mail alias (and didn't like the idea of pushing directly to lkml where it would be likely to be overlooked), will use that next time. I'd like to know _how_ the userspace app should actually work, but I'll leave that for another day ... (documentation is rather scarce).

Thanks for forwarding, and thanks for getting it resolved.

Jaco
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors