netdev - Re: [PATCH v2 0/8] do not leave dangling sk pointers in pf->create functions

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20241007215734.72373-1-kuniyu@amazon.com>
Date: Mon, 7 Oct 2024 14:57:34 -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>, <stefan@...enfreihafen.org>,
	<willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH v2 0/8] do not leave dangling sk pointers in pf->create functions

> [PATCH v2 0/8] do not leave dangling sk pointers in pf->create functions

For the future patches, please specify the target tree, net or net-next.


From: Ignat Korchagin <ignat@...udflare.com>
Date: Mon,  7 Oct 2024 22:34:54 +0100
> Some protocol family create() implementations have an error path after
> allocating the sk object and calling sock_init_data(). sock_init_data()
> attaches the allocated sk object to the sock object, provided by the
> caller.
> 
> If the create() implementation errors out after calling sock_init_data(),
> it releases the allocated sk object, but the caller ends up having a
> dangling sk pointer in its sock object on return. Subsequent manipulations
> on this sock object may try to access the sk pointer, because it is not
> NULL thus creating a use-after-free scenario.
> 
> While the first patch in the series should be enough to handle this
> scenario Eric Dumazet suggested that it would be a good idea to refactor
> the code for the af_packet implementation to avoid the error path, which
> leaves a dangling pointer, because it may be better for some tools like
> kmemleak. I went a bit further and tried to actually fix all the
> implementations, which could potentially leave a dangling sk pointer.

I feel patch 2-8 are net-next materials as the first patch is enough
to fix the issue.

Also, once all protocols have moved sock_init_data() after the last
failure point, we can change the patch 1's part to

	err = pf->create(net, sock, protocol, kern);
	if (err) {
		DEBUG_NET_WARN_ON_ONCE(sock->sk);
		goto out_module_put;
	}

for the future protocols.