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  linux-cve-announce  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:	Wed, 20 Jun 2007 07:13:22 -0700
From:	"Stephens, Allan" <>
To:	"Patrick McHardy" <>,
	"Florian Westphal" <>
Cc:	<>, <>,
	<>, <>
Subject: RE: [PATCH] TIPC: Fix infinite loop in netlink handler

Patrick McHardy wrote:
> Florian Westphal wrote:
> > From: Florian Westphal <>
> > 
> > The tipc netlink config handler uses the nlmsg_pid from the request 
> > header as destination for its reply. If the application initialized 
> > nlmsg_pid to 0, the reply is looped back to the kernel, causing 
> > hangup. Fix: use nlmsg_pid of the skb that triggered the request.
> > 
> > -		genlmsg_unicast(rep_buf, req_nlh->nlmsg_pid);
> > +		genlmsg_unicast(rep_buf, NETLINK_CB(skb).pid);
> This is the second time we're seeing this bug within a few 
> weeks, maybe we should rename NETLINK_CB(skb).pid to dst_pid 
> to avoid similar confusion in the future? We could even 
> rename nlmsg_pid to nlmsg_src within the kernel, which should 
> make it completely clear what is being refered to.

I'm assuming that Patrick's first suggestion should have read "rename
NETLINK_CB(skb).pid to src_pid", as there is already a "dst_pid" field
in the netlink_skb_parms structure type.

I agree that such a change would make things clearer to folks who are
relative novices when it comes to Netlink.

-- Al
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