lists.openwall.net | 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
| ||
|
Date: Wed, 20 Jun 2007 07:13:22 -0700 From: "Stephens, Allan" <allan.stephens@...driver.com> To: "Patrick McHardy" <kaber@...sh.net>, "Florian Westphal" <fw-kernel@...len.de> Cc: <netdev@...r.kernel.org>, <jon.maloy@...csson.com>, <per.liden@...csson.com>, <tipc-discussion@...ts.sourceforge.net> Subject: RE: [PATCH] TIPC: Fix infinite loop in netlink handler Patrick McHardy wrote: > Florian Westphal wrote: > > From: Florian Westphal <fw@...len.de> > > > > 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists