From: Jakub Kicinski <kuba@kernel.org>
To: Fedor Pchelkin <pchelkin@ispras.ru>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
Johan Hedberg <johan.hedberg@gmail.com>,
Marcel Holtmann <marcel@holtmann.org>,
Ignat Korchagin <ignat@cloudflare.com>,
Kuniyuki Iwashima <kuniyu@amazon.com>,
Eric Dumazet <edumazet@google.com>,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org, netdev@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
Date: Thu, 9 Jan 2025 07:11:02 -0800 [thread overview]
Message-ID: <20250109071102.23a5205d@kernel.org> (raw)
In-Reply-To: <20250109-fbd0cb9fa9036bc76ea9b003-pchelkin@ispras.ru>
On Thu, 9 Jan 2025 10:47:12 +0300 Fedor Pchelkin wrote:
> On Wed, 18. Dec 00:19, Fedor Pchelkin wrote:
> > A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
> > from l2cap_sock_new_connection_cb() and the error handling paths should
> > also be aware of it.
> >
> > Seemingly a more elegant solution would be to swap bt_sock_alloc() and
> > l2cap_chan_create() calls since they are not interdependent to that moment
> > but then l2cap_chan_create() adds the soon to be deallocated and still
> > dummy-initialized channel to the global list accessible by many L2CAP
> > paths. The channel would be removed from the list in short period of time
> > but be a bit more straight-forward here and just check for NULL instead of
> > changing the order of function calls.
> >
> > Found by Linux Verification Center (linuxtesting.org) with SVACE static
> > analysis tool.
> >
> > Fixes: 7c4f78cdb8e7 ("Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
> > ---
>
> Urgh.. a bit confused about which tree the patch should go to - net or
> bluetooth.
>
> I've now noticed the Fixes commit went directly via net-next as part of a
> series (despite "Bluetooth: L2CAP:" patches usually go through bluetooth
> tree first). So what about this patch?
7c4f78cdb8e7 went directly to net-next because it was a larger series touching
multiple sub-subsystems:
$ git log -12 --graph --oneline 2d859aff775df54
* 2d859aff775d Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'
|\
| * 18429e6e0c2a Revert "net: do not leave a dangling sk pointer, when socket creation fails"
| * 48156296a08c net: warn, if pf->create does not clear sock->sk on error
| * 9df99c395d0f net: inet6: do not leave a dangling sk pointer in inet6_create()
| * 9365fa510c6f net: inet: do not leave a dangling sk pointer in inet_create()
| * b4fcd63f6ef7 net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()
| * 811a7ca7320c net: af_can: do not leave a dangling sk pointer in can_create()
| * 3945c799f12b Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()
| * 7c4f78cdb8e7 Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
| * 46f2a11cb82b af_packet: avoid erroring out after sock_init_data() in packet_create()
|/
* 397006ba5d91 net/sched: cbs: Fix integer overflow in cbs_set_port_rate()
next prev parent reply other threads:[~2025-01-09 15:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 21:19 [PATCH] Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc Fedor Pchelkin
2024-12-17 21:54 ` bluez.test.bot
2024-12-21 8:17 ` [PATCH] " Kuniyuki Iwashima
2025-01-09 7:47 ` Fedor Pchelkin
2025-01-09 15:11 ` Jakub Kicinski [this message]
2025-01-09 15:17 ` Fedor Pchelkin
2025-01-09 16:16 ` patchwork-bot+bluetooth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250109071102.23a5205d@kernel.org \
--to=kuba@kernel.org \
--cc=edumazet@google.com \
--cc=ignat@cloudflare.com \
--cc=johan.hedberg@gmail.com \
--cc=kuniyu@amazon.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=lvc-project@linuxtesting.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=pchelkin@ispras.ru \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.