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