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

[Kuniyuki Iwashima <kuniyu@amazon.com>]

> [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@cloudflare.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.