[GIT PULL] bluetooth 2026-03-19

[GIT PULL] bluetooth 2026-03-19

[Luiz Augusto von Dentz]

The following changes since commit 7ab4a7c5d969642782b8a5b608da0dd02aa9f229:

  MPTCP: fix lock class name family in pm_nl_create_listen_socket (2026-03-19 09:37:48 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-03-19

for you to fetch changes up to 761fb8ec8778f0caf2bba5a41e3cff1ea86974f3:

  Bluetooth: L2CAP: Fix regressions caused by reusing ident (2026-03-19 14:44:25 -0400)

----------------------------------------------------------------
bluetooth pull request for net:

 - hci_ll: Fix firmware leak on error path
 - hci_sync: annotate data-races around hdev->req_status
 - L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb
 - L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()
 - L2CAP: Fix regressions caused by reusing ident
 - L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req
 - MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete
 - SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold

----------------------------------------------------------------
Anas Iqbal (1):
      Bluetooth: hci_ll: Fix firmware leak on error path

Cen Zhang (1):
      Bluetooth: hci_sync: annotate data-races around hdev->req_status

Helen Koike (1):
      Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb

Hyunwoo Kim (2):
      Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()
      Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold

Luiz Augusto von Dentz (2):
      Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete
      Bluetooth: L2CAP: Fix regressions caused by reusing ident

Minseo Park (1):
      Bluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req

 drivers/bluetooth/hci_ll.c    |  2 ++
 include/net/bluetooth/l2cap.h |  1 +
 net/bluetooth/hci_conn.c      |  2 +-
 net/bluetooth/hci_core.c      |  2 +-
 net/bluetooth/hci_sync.c      | 20 ++++++++++----------
 net/bluetooth/l2cap_core.c    | 40 ++++++++++++++++++++++++++++++++++------
 net/bluetooth/l2cap_sock.c    |  3 +++
 net/bluetooth/mgmt.c          |  2 +-
 net/bluetooth/sco.c           | 10 +++++++---
 9 files changed, 60 insertions(+), 22 deletions(-)

Re: [GIT PULL] bluetooth 2026-03-19

[patchwork-bot+netdevbpf]

Hello:

This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 19 Mar 2026 15:04:55 -0400 you wrote:
> The following changes since commit 7ab4a7c5d969642782b8a5b608da0dd02aa9f229:
> 
>   MPTCP: fix lock class name family in pm_nl_create_listen_socket (2026-03-19 09:37:48 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-03-19
> 
> [...]

Here is the summary with links:
  - [GIT,PULL] bluetooth 2026-03-19
    https://git.kernel.org/netdev/net/c/57ce3b2e9cda

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Thorsten Leemhuis]

On 3/20/26 01:00, patchwork-bot+netdevbpf@kernel.org wrote:
> This pull request was applied to netdev/net.git (main)
> by Jakub Kicinski <kuba@kernel.org>:
> 
> On Thu, 19 Mar 2026 15:04:55 -0400 you wrote:
>> The following changes since commit 7ab4a7c5d969642782b8a5b608da0dd02aa9f229:
>>
>>   MPTCP: fix lock class name family in pm_nl_create_listen_socket (2026-03-19 09:37:48 -0700)
>>
>> are available in the Git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-03-19
>>
>> [...]
> 
> Here is the summary with links:
>   - [GIT,PULL] bluetooth 2026-03-19
>     https://git.kernel.org/netdev/net/c/57ce3b2e9cda

[preface: sorry for being a pest again and making life of maintainers
harder with mails like this; but I think Linus (CCed) wants me to bring
up situations like this; Linus, if I'm wrong, please do not hesitate to
tell me]

The quoted bluetooth pull to net afaics came a tiny bit too late for
this week's net PR to mainline. I assume there won't be another this
week, as that would be unusual from a look at the history (and well, if
I'm wrong I'm happy!). That is kind of unfortunate, as those bluetooth
changes contained a fix[1] for a regression that at least three people
reported (and I know of at least one other person that was affected)[2].
A regression that is known for nearly a month now and thus already took
way longer than the "fix within a week, preferably before the next rc."
rule of thumb Linus recently mentioned[3].

We had a similar situation last week already with the netfilter PR to
net[4], which came on a Friday -- and missed last week's net PR to
mainline, so those netfilter changes were only mainlined yesterday. Due
to this a revert[5] that fixes a regression multiple people reported[6]
missed -rc4 and will only be in -rc5.

These two examples make me wonder if we might want to optimize something
here. Have a second net PR to mainline in some weeks? Or should the net
PR to mainline maybe be sent later during the week whenever possible
(say on a Friday)? That would have avoided the problem. And yes, I know,
Linus at some point due to last-minute problems asked to send net
mainline PRs mid-week. But he iirc (not totally sure, hence correct me
if I'm wrong) recently mentioned that things have improved. That's why
I'm wondering if we should forget about the mid-week thing again and
shift things a little.

Ciao, Thorsten

P.S. Once again I wonder if we should have a dedicated tree to collect
and quickly mainline regression fixes subsystem maintainers ACKed -- but
at the same time I think strongly that it's a totally stupid idea, as
bypassing subsystem has many downsides (like bypassing subsystem
specific CIs, the need for backmerges [or duplicated commits] and things
like that).

[1]
https://lore.kernel.org/all/20260319152247.13225-1-luiz.dentz@gmail.com/
-- in next as 761fb8ec8778f0
[2]
https://lore.kernel.org/all/20260301233619.1807980-1-joanbrugueram@gmail.com/
and links to bugzilla in that thread
[3]
https://lore.kernel.org/all/CAHk-%3Dwi86AosXs66-yi54%2BmpQjPu0upxB8ZAfG%2BLsMyJmcuMSA@mail.gmail.com/
[4] https://lore.kernel.org/all/20260313150614.21177-1-fw@strlen.de/
[5] https://lore.kernel.org/all/20260313150614.21177-5-fw@strlen.de/
[6] https://bugzilla.kernel.org/show_bug.cgi?id=221152,
https://bugzilla.kernel.org/show_bug.cgi?id=221158 , and
https://lore.kernel.org/all/143e1a402ad78dd7076516a6ceb637f378310b16.camel@sapience.com/
(some of those are with stable kernels, where the culprit was backported
and reverted earlier already due to the regression)

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Luiz Augusto von Dentz]

Hi Thorsten,

On Fri, Mar 20, 2026 at 12:47 PM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> On 3/20/26 01:00, patchwork-bot+netdevbpf@kernel.org wrote:
> > This pull request was applied to netdev/net.git (main)
> > by Jakub Kicinski <kuba@kernel.org>:
> >
> > On Thu, 19 Mar 2026 15:04:55 -0400 you wrote:
> >> The following changes since commit 7ab4a7c5d969642782b8a5b608da0dd02aa9f229:
> >>
> >>   MPTCP: fix lock class name family in pm_nl_create_listen_socket (2026-03-19 09:37:48 -0700)
> >>
> >> are available in the Git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-03-19
> >>
> >> [...]
> >
> > Here is the summary with links:
> >   - [GIT,PULL] bluetooth 2026-03-19
> >     https://git.kernel.org/netdev/net/c/57ce3b2e9cda
>
> [preface: sorry for being a pest again and making life of maintainers
> harder with mails like this; but I think Linus (CCed) wants me to bring
> up situations like this; Linus, if I'm wrong, please do not hesitate to
> tell me]
>
> The quoted bluetooth pull to net afaics came a tiny bit too late for
> this week's net PR to mainline. I assume there won't be another this
> week, as that would be unusual from a look at the history (and well, if
> I'm wrong I'm happy!). That is kind of unfortunate, as those bluetooth
> changes contained a fix[1] for a regression that at least three people
> reported (and I know of at least one other person that was affected)[2].
> A regression that is known for nearly a month now and thus already took
> way longer than the "fix within a week, preferably before the next rc."
> rule of thumb Linus recently mentioned[3].

Afaik, it was tagged as regression on March 1st afaik, according to
[2]; traces were only provided on March 15th, so yeah it was fixed
within a week once the necessary traces were supplied.

> We had a similar situation last week already with the netfilter PR to
> net[4], which came on a Friday -- and missed last week's net PR to
> mainline, so those netfilter changes were only mainlined yesterday. Due
> to this a revert[5] that fixes a regression multiple people reported[6]
> missed -rc4 and will only be in -rc5.
>
> These two examples make me wonder if we might want to optimize something
> here. Have a second net PR to mainline in some weeks? Or should the net
> PR to mainline maybe be sent later during the week whenever possible
> (say on a Friday)? That would have avoided the problem. And yes, I know,
> Linus at some point due to last-minute problems asked to send net
> mainline PRs mid-week. But he iirc (not totally sure, hence correct me
> if I'm wrong) recently mentioned that things have improved. That's why
> I'm wondering if we should forget about the mid-week thing again and
> shift things a little.

Bluetooth regressions are normally device-specific, though. In this
case, the regression was introduced to pass a new Bluetooth
Qualification test, so we would have to weigh what is more important:
compliance or interoperability? Which would probably be a split
decision, though we always tried to balance that, since both are
important. However, I can't remove a valid compliance fix just because
a user (later more appeared which raized the severity) said his device
stopped working.

> Ciao, Thorsten
>
> P.S. Once again I wonder if we should have a dedicated tree to collect
> and quickly mainline regression fixes subsystem maintainers ACKed -- but
> at the same time I think strongly that it's a totally stupid idea, as
> bypassing subsystem has many downsides (like bypassing subsystem
> specific CIs, the need for backmerges [or duplicated commits] and things
> like that).
>
> [1]
> https://lore.kernel.org/all/20260319152247.13225-1-luiz.dentz@gmail.com/
> -- in next as 761fb8ec8778f0
> [2]
> https://lore.kernel.org/all/20260301233619.1807980-1-joanbrugueram@gmail.com/
> and links to bugzilla in that thread
> [3]
> https://lore.kernel.org/all/CAHk-%3Dwi86AosXs66-yi54%2BmpQjPu0upxB8ZAfG%2BLsMyJmcuMSA@mail.gmail.com/
> [4] https://lore.kernel.org/all/20260313150614.21177-1-fw@strlen.de/
> [5] https://lore.kernel.org/all/20260313150614.21177-5-fw@strlen.de/
> [6] https://bugzilla.kernel.org/show_bug.cgi?id=221152,
> https://bugzilla.kernel.org/show_bug.cgi?id=221158 , and
> https://lore.kernel.org/all/143e1a402ad78dd7076516a6ceb637f378310b16.camel@sapience.com/
> (some of those are with stable kernels, where the culprit was backported
> and reverted earlier already due to the regression)



-- 
Luiz Augusto von Dentz

Re: bluetooth regression fix likely to miss -rc5

[Thorsten Leemhuis]

On 3/20/26 19:02, Luiz Augusto von Dentz wrote:
> On Fri, Mar 20, 2026 at 12:47 PM Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>> On 3/20/26 01:00, patchwork-bot+netdevbpf@kernel.org wrote:
>
>> The quoted bluetooth pull to net afaics came a tiny bit too late for
>> this week's net PR to mainline. I assume there won't be another this
>> week, as that would be unusual from a look at the history (and well, if
>> I'm wrong I'm happy!). That is kind of unfortunate, as those bluetooth
>> changes contained a fix[1] for a regression that at least three people
>> reported (and I know of at least one other person that was affected)[2].
>> A regression that is known for nearly a month now and thus already took
>> way longer than the "fix within a week, preferably before the next rc."
>> rule of thumb Linus recently mentioned[3].
> 
> Afaik, it was tagged as regression on March 1st afaik, according to
> [2];

Well, the first report was 2026-02-22
https://bugzilla.kernel.org/show_bug.cgi?id=221120

I don't blame you for missing that, as it took some time to reach you
due to the know deficits of our bugzilla setup (and looking back I could
and should have forwarded it faster once I had noticed it) -- which is
another reason to change something there, but that is a different topic
(see the recent discussion on the ksummit list).

> traces were only provided on March 15th, so yeah it was fixed
> within a week once the necessary traces were supplied.

Sure, and I can fully understand that you need traces to fix this and
that not reverting the culprit helps motivating someone to provide them.
But OTOH from Linus statement in [3] it sounds like he would have
preferred to see this fixed faster through a revert.

I guess it's not too much of the problem that it took a bit longer from
the report to a fix. But thx to your efforts (many thx for that) we now
have a fix, so I'd say: let's mainline it quickly to (a) get it tested
and (b) prevent more people from running into this, as then they might
bisect for nothing.

Ciao, Thorsten

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Linus Torvalds]

On Fri, 20 Mar 2026 at 11:02, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Bluetooth regressions are normally device-specific, though. In this
> case, the regression was introduced to pass a new Bluetooth
> Qualification test, so we would have to weigh what is more important:
> compliance or interoperability?

What?

That's nonsensical.

Compliance with some paper standard or artificial test is *COMPLETELY*
irrelevant in the face of an actual user experience regression.

Because when reality and theory collide, theory goes out the window.

There's no "weighing what is more important". None. Users are a
million times more important than specs or tests.

And yes, the world is full of hardware that is not actually compliant
with various standards that it's _supposed_ to be compliant with.

That hardware may admittedly often not be great, and we may all wish
that it didn't exist, but hey, that's the thing about reality: it's
often messy.

And sometimes it's the standard that is wrong.

> I can't remove a valid compliance fix just because
> a user (later more appeared which raized the severity) said his device
> stopped working.

Of course you can.

The test or the standard may be entirely invalid. Not unheard of.

But even more common is that the "fix" that made the test work may
simply be wrong.

Because that "fix some case, break something else" is in a fairly
common pattern.  And that just makes the fix invalid and buggy.

And we have a hard rule on regressions exactly BECAUSE of that
situation: having a "fix one thing, break another" is what the
suspend/resume code had for years and years.

The constant "one step forward, two steps back" dance was what made us
have that hard rule about regressions, because it's better to have a
stable base with known problems - that you can perhaps document - than
have a base where the problems just shift around like quicksand and
users are understandably nervous about upgrading their system, because
they never know if the end result works or not.

So the whole "it's a fix so we can't remove it" is simple not a valid
argument. It's absolutely wrong. Because a fix that causes regressions
is BY DEFINITION not a fix at all.

                Linus

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Linus Torvalds]

On Fri, 20 Mar 2026 at 14:03, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That hardware may admittedly often not be great, and we may all wish
> that it didn't exist, but hey, that's the thing about reality: it's
> often messy.

Of course, the thing about "reality is often messy" is that then you
end up with the truly conflicting situations where there are other
complications: security issues can sometimes mean that you *really*
can't just revert a regression fix, because while paper standards and
artificial tests are relatively worthless (compared to a user
regression report), a severe security problem obviously isn't...

Also, if the regression reports then come in late, people may have
started relying on the new behavior, and reverting things then causes
its own set of regressions.

But when you get a regression report quickly during the early -rc
period, that tends to mean that it's either a really bad fix, or it's
just a very common piece of bad hardware (or a shared bug across many
different hw implementations - which obviously is often then due to
some common chip or firmware implementation or whatever)

               Linus

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Luiz Augusto von Dentz]

Hi Linus,

On Fri, Mar 20, 2026 at 5:19 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, 20 Mar 2026 at 14:03, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > That hardware may admittedly often not be great, and we may all wish
> > that it didn't exist, but hey, that's the thing about reality: it's
> > often messy.
>
> Of course, the thing about "reality is often messy" is that then you
> end up with the truly conflicting situations where there are other
> complications: security issues can sometimes mean that you *really*
> can't just revert a regression fix, because while paper standards and
> artificial tests are relatively worthless (compared to a user
> regression report), a severe security problem obviously isn't...
>
> Also, if the regression reports then come in late, people may have
> started relying on the new behavior, and reverting things then causes
> its own set of regressions.
>
> But when you get a regression report quickly during the early -rc
> period, that tends to mean that it's either a really bad fix, or it's
> just a very common piece of bad hardware (or a shared bug across many
> different hw implementations - which obviously is often then due to
> some common chip or firmware implementation or whatever)

While I agree specs sometimes tend to be worthless they sort of guide
future implementations, so in the end it is not always black or white.
Anyway, since this escalated rather quickly I think next time I'll
just revert and work out the situation on bluetooth-next, rather than
trying to access with the reporter and risk  delaying a fix.


-- 
Luiz Augusto von Dentz

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Linus Torvalds]

On Sat, 21 Mar 2026 at 11:50, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Anyway, since this escalated rather quickly I think next time I'll
> just revert and work out the situation on bluetooth-next, rather than
> trying to access with the reporter and risk  delaying a fix.

Yes, I think that lowers the risk - and stress - for these kinds of things.

Generally, I think that if there are regressions reports that come in
while we're still in the -rc series and the problem hasn't hit an
actual release yet, it's probably worth reverting simply to get time
to think about the issue more.

(Of course - some bugs are simply obvious once somebody has bisected
the issue, and don't need any more time to think about it more. "D'oh,
too much cut-and-paste, obvious fix is obvious" - just apply the fix.
But if it's a situation where it's not entirely clear why things are
going south, and a revert is simple and straightforward, I don't think
there's much real downside to just going "ok, I don't know what's
going on, let's revert and rethink this")

The *good* thing about early regression reports is that typically the
people who test rc kernels are also very responsive to "can you test
this change" kinds of patches. So there is usually then a good path
forward for trying alternate approaches.

              Linus

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Jakub Kicinski]

On Fri, 20 Mar 2026 14:02:34 -0400 Luiz Augusto von Dentz wrote:
> Afaik, it was tagged as regression on March 1st afaik, according to
> [2]; traces were only provided on March 15th, so yeah it was fixed
> within a week once the necessary traces were supplied.

Hi Luiz, I don't really care about the complaint, just wanted to check
whether you know that we always send the PR on Thu (either AM or PM
depending on which maintainer is handling it)? If you do then nothing
to see here, we are all doing our best. But if it's not crystal clear
I should probably ping all sub-trees to remind folks.

Re: bluetooth regression fix likely to miss -rc5 (was: Re: [GIT PULL] bluetooth 2026-03-19)

[Luiz Augusto von Dentz]

Hi Jakub,

On Fri, Mar 20, 2026 at 8:52 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 20 Mar 2026 14:02:34 -0400 Luiz Augusto von Dentz wrote:
> > Afaik, it was tagged as regression on March 1st afaik, according to
> > [2]; traces were only provided on March 15th, so yeah it was fixed
> > within a week once the necessary traces were supplied.
>
> Hi Luiz, I don't really care about the complaint, just wanted to check
> whether you know that we always send the PR on Thu (either AM or PM
> depending on which maintainer is handling it)? If you do then nothing
> to see here, we are all doing our best. But if it's not crystal clear
> I should probably ping all sub-trees to remind folks.

Sure thing, normally I would have send it sooner but I did want to
make sure the regression fix was included, I will put a reminder to
send the PR by Wednesday to make sure that git to you ahead of time.

-- 
Luiz Augusto von Dentz