lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 05 Jul 2007 09:53:30 -0400
From:	jamal <>
To:	Johannes Berg <>
Cc:	netdev <>, Patrick McHardy <>,
	Thomas Graf <>
Subject: Re: multicasting netlink messages to groups > 31 from userspace

This email captures the essence of the thread, so let me start here. 
I dont know if i read well enough all the details, but i think i have a
good grasp of the discusion.

To just pick on mentioned issues on the thread which i picked up:
- i think it is fairly usable by netlink to be used as an IPC. The fact
you can do mcast is a huge advantage. i.e i should be able to send to
kernel/user and a mcast group to which a "netlink sniffer" is connected
for debugging etc.
The DoS issue is applicable IMO to any IPC. i.e
if i have access to sending to you, i can send you many messages and
fill up your unix socket rcvq etc.
- On reliability: This is something you will have to deal with yourself
in your application.
For example you could have netlink ACKs sent back to you by all
receivers to the mcast grp (just like the kernel does when you unicast
and ask for acknowledgement).
- In addition to the netlink sock open/close that Patrick mentioned, you
can listen to generic netlink events on the accounting/task netlink and
find out when processes are created/destroyed if that is useful. I
couldnt tell why you needed to know this...

On Tue, 2007-03-07 at 21:51 +0200, Johannes Berg wrote:
> Hey,
> Looking through the code that uses NL_NONROOT_SEND I just realised that
> it's impossible to send multicast messages from userspace to multicast
> groups with IDs higher than 31. That's not really good given that
> everywhere else we handle multicast groups up to 2^32-1 :/

Yes, this is TheWayItHasBeen(tm).
Patrick had a patch a while back to allow for subscribing to higher
groups because bind() has a similar issue in that it allows you only to
subscribe to the first 32. So it is logical to fix connect, and sendmsg
in a similar fashion.

> Unfortunately, I haven't found any good way to fix this; in fact the
> only way to fix it backward-compatibly I could come up with so far is to
> extend struct sockaddr_nl by "__u32 nl_group;" and use that in
> netlink_sendmsg instead of nl_groups when msg_namelen is large enough
> and I'm not even sure that checking msg_namelen is enough, apps could
> give you a length much longer than the actual structure... Maybe
> additionally require that nl_groups is set to ~0 or something. 

We had long chats when Patricks patch went in on this specific issue. I
cant remember the outcome - i remember vaguely that something was going
to break if you muck with sockaddr_nl

> The same
> should be done for netlink_connect() then.

Fixing connect IMO would be a good first start because if you do
connect() to the right group(s) before sendsmg() you could send
to the correct group.

> It would of course be possible to add a new sockopt

This maybe your best first starting option IMO. It will be in similar
spirit to Patricks bind() fix.

> but that prevents you from sending messages
> to multiple high groups with sendmsg(), 

Iirc, i dont think we can do that anymore. But we can introduce a new
scheme to allow for this. For example, could you not use CMSG to specify
an explicit list of groups on sendmsg? IIRC, Patrick used CMSG to report
on rcv which group a msg was received on. 


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists