From: Ignat Korchagin <[email protected]> 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 <[email protected]>
Reviewed-by: Kuniyuki Iwashima <[email protected]>
