linux-kernel - Re: [PATCH v2 1/8] net: explicitly clear the sk pointer, when pf->create fails

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: <20241007214733.71958-1-kuniyu@amazon.com>
Date: Mon, 7 Oct 2024 14:47:33 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <ignat@...udflare.com>
CC: <alex.aring@...il.com>, <alibuda@...ux.alibaba.com>,
	<davem@...emloft.net>, <dsahern@...nel.org>, <edumazet@...gle.com>,
	<johan.hedberg@...il.com>, <kernel-team@...udflare.com>, <kuba@...nel.org>,
	<kuniyu@...zon.com>, <linux-bluetooth@...r.kernel.org>,
	<linux-can@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-wpan@...r.kernel.org>, <luiz.dentz@...il.com>, <marcel@...tmann.org>,
	<miquel.raynal@...tlin.com>, <mkl@...gutronix.de>, <netdev@...r.kernel.org>,
	<pabeni@...hat.com>, <socketcan@...tkopp.net>, <stable@...r.kernel.org>,
	<stefan@...enfreihafen.org>, <willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH v2 1/8] net: explicitly clear the sk pointer, when pf->create fails

From: Ignat Korchagin <ignat@...udflare.com>
Date: Mon,  7 Oct 2024 22:34:55 +0100
> We have recently noticed the exact same KASAN splat as in commit
> 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket
> creation fails"). The problem is that commit did not fully address the
> problem, as some pf->create implementations do not use sk_common_release
> in their error paths.
> 
> For example, we can use the same reproducer as in the above commit, but
> changing ping to arping. arping uses AF_PACKET socket and if packet_create
> fails, it will just sk_free the allocated sk object.
> 
> While we could chase all the pf->create implementations and make sure they
> NULL the freed sk object on error from the socket, we can't guarantee
> future protocols will not make the same mistake.
> 
> So it is easier to just explicitly NULL the sk pointer upon return from
> pf->create in __sock_create. We do know that pf->create always releases the
> allocated sk object on error, so if the pointer is not NULL, it is
> definitely dangling.
> 
> Fixes: 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails")
> Signed-off-by: Ignat Korchagin <ignat@...udflare.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@...zon.com>