]> www.infradead.org Git - users/jedix/linux-maple.git/commit
Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'
authorJakub Kicinski <kuba@kernel.org>
Wed, 16 Oct 2024 01:43:11 +0000 (18:43 -0700)
committerJakub Kicinski <kuba@kernel.org>
Wed, 16 Oct 2024 01:43:11 +0000 (18:43 -0700)
commit2d859aff775df5486667aa895a7e4b9c2e98e348
treed4680ce134db3b56d799c0ea59ca6d38e27f34fb
parent397006ba5d918f9b74e734867e8fddbc36dc2282
parent18429e6e0c2ad26250862a786964d8c73400d9a0
Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'

Ignat Korchagin says:

====================
do not leave dangling sk pointers in pf->create functions

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.

We have implemented a stable hotfix in commit 631083143315
("net: explicitly clear the sk pointer, when pf->create fails"), but this
series aims to fix it properly by going through each of the pf->create()
implementations and making sure they all don't return a sock object with
a dangling pointer on error.
====================

Link: https://patch.msgid.link/20241014153808.51894-1-ignat@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>