netdev - Re: [Security] [PATCH] infinite recursion in netlink

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.98.0704251311270.9964@woody.linux-foundation.org>
Date:	Wed, 25 Apr 2007 13:15:12 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alexey Kuznetsov <kuznet@....inr.ac.ru>
cc:	davem@...emloft.net, security@...nel.org, greg@...ah.com,
	netdev@...r.kernel.org, jaco@...on.co.za
Subject: Re: [Security] [PATCH] infinite recursion in netlink



On Wed, 25 Apr 2007, Alexey Kuznetsov wrote:
> 
> Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel,
> which resulted in infinite recursion and stack overflow.

So I assume it's this line that actually _fixes_ it:

> -	pid = nlh->nlmsg_pid;           /*pid of sending process */
> +	pid = NETLINK_CB(skb).pid;       /* pid of sending process */
>  	NETLINK_CB(skb).pid = 0;         /* from kernel */
>  	NETLINK_CB(skb).dst_group = 0;  /* unicast */
>  	netlink_unicast(sk, skb, pid, MSG_DONTWAIT);

No?

If so, shouldn't we also have some safety-net to make sure it doesn't 
still get routed back forever, ie adding something like

	if (!pid) {
		skb_free(skb);
		return -EINVAL;
	}

or similar? I don't know the netlink layer from a dolphin, but if the old 
code could cause infinite recursion, it sounds like the new code could too 
with the right pid, since the only change is the choice of pid.

Yes/No/This is why Linus is a dickweed and doesn't understand the problem?

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