[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id:
<172910555679.1899946.4586742822023966255.git-patchwork-notify@kernel.org>
Date: Wed, 16 Oct 2024 19:05:56 +0000
From: patchwork-bot+bluetooth@...nel.org
To: Ignat Korchagin <ignat@...udflare.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com,
socketcan@...tkopp.net, mkl@...gutronix.de, alex.aring@...il.com,
stefan@...enfreihafen.org, miquel.raynal@...tlin.com, dsahern@...nel.org,
willemdebruijn.kernel@...il.com, linux-bluetooth@...r.kernel.org,
linux-can@...r.kernel.org, linux-wpan@...r.kernel.org,
kernel-team@...udflare.com, kuniyu@...zon.com, alibuda@...ux.alibaba.com
Subject: Re: [PATCH net-next v3 0/9] do not leave dangling sk pointers in
pf->create functions
Hello:
This series was applied to bluetooth/bluetooth-next.git (master)
by Jakub Kicinski <kuba@...nel.org>:
On Mon, 14 Oct 2024 16:37:59 +0100 you wrote:
> 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.
>
> [...]
Here is the summary with links:
- [net-next,v3,1/9] af_packet: avoid erroring out after sock_init_data() in packet_create()
https://git.kernel.org/bluetooth/bluetooth-next/c/46f2a11cb82b
- [net-next,v3,2/9] Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
https://git.kernel.org/bluetooth/bluetooth-next/c/7c4f78cdb8e7
- [net-next,v3,3/9] Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()
https://git.kernel.org/bluetooth/bluetooth-next/c/3945c799f12b
- [net-next,v3,4/9] net: af_can: do not leave a dangling sk pointer in can_create()
https://git.kernel.org/bluetooth/bluetooth-next/c/811a7ca7320c
- [net-next,v3,5/9] net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()
https://git.kernel.org/bluetooth/bluetooth-next/c/b4fcd63f6ef7
- [net-next,v3,6/9] net: inet: do not leave a dangling sk pointer in inet_create()
https://git.kernel.org/bluetooth/bluetooth-next/c/9365fa510c6f
- [net-next,v3,7/9] net: inet6: do not leave a dangling sk pointer in inet6_create()
https://git.kernel.org/bluetooth/bluetooth-next/c/9df99c395d0f
- [net-next,v3,8/9] net: warn, if pf->create does not clear sock->sk on error
https://git.kernel.org/bluetooth/bluetooth-next/c/48156296a08c
- [net-next,v3,9/9] Revert "net: do not leave a dangling sk pointer, when socket creation fails"
https://git.kernel.org/bluetooth/bluetooth-next/c/18429e6e0c2a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists