* Re: [PATCH v2] Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister
From: patchwork-bot+bluetooth @ 2026-04-22 17:20 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: linux-bluetooth
In-Reply-To: <afc0037c7237e101b50b68d969cc4202bede5f92.1775931137.git.pav@iki.fi>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Sat, 11 Apr 2026 21:15:09 +0300 you wrote:
> 6lowpan.c has theoretically conflicting lock orderings, which lockdep
> complains about:
>
> a) rtnl_lock > hdev->workqueue
>
> from 6lowpan.c:delete_netdev -> rtnl_lock -> device_del
> -> put_device(parent) -> hci_release_dev -> destroy_workqueue
>
> [...]
Here is the summary with links:
- [v2] Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister
https://git.kernel.org/bluetooth/bluetooth-next/c/87151e363b7e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-22 16:41 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1084033
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* RE: [BlueZ,v1] input: Fix checking LE bonding on HIDP
From: bluez.test.bot @ 2026-04-22 16:40 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260422150328.2062359-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1084336
---Test result---
Test Summary:
CheckPatch PASS 0.34 seconds
GitLint PASS 0.24 seconds
BuildEll PASS 20.31 seconds
BluezMake PASS 644.74 seconds
MakeCheck PASS 0.92 seconds
MakeDistcheck PASS 246.53 seconds
CheckValgrind PASS 221.43 seconds
CheckSmatch PASS 350.33 seconds
bluezmakeextell PASS 181.69 seconds
IncrementalBuild PASS 646.76 seconds
ScanBuild PASS 1025.97 seconds
https://github.com/bluez/bluez/pull/2062
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v3 0/2] Bluetooth: virtio_bt: harden rx against untrusted backend
From: patchwork-bot+bluetooth @ 2026-04-22 16:00 UTC (permalink / raw)
To: Michael Bommarito
Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel, soenke.huster,
mst, virtualization
In-Reply-To: <20260421170845.3469513-1-michael.bommarito@gmail.com>
Hello:
This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 21 Apr 2026 13:08:43 -0400 you wrote:
> Respin of the virtio_bt rx hardening patch, split per Luiz's
> request on the v2 thread:
>
> https://lore.kernel.org/linux-bluetooth/20260421151659.3326690-1-michael.bommarito@gmail.com/
>
> v2 bundled two independent hazards in one commit and the commit
> message got convoluted trying to explain them together. This v3
> keeps each hazard in its own patch so the rationale for each is
> self-contained.
>
> [...]
Here is the summary with links:
- [v3,1/2] Bluetooth: virtio_bt: clamp rx length before skb_put
https://git.kernel.org/bluetooth/bluetooth-next/c/041f524fb455
- [v3,2/2] Bluetooth: virtio_bt: validate rx pkt_type header length
https://git.kernel.org/bluetooth/bluetooth-next/c/d677b827eea1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] Bluetooth: HIDP: guard session->conn in hidp_connection_del
From: Luiz Augusto von Dentz @ 2026-04-22 15:49 UTC (permalink / raw)
To: Michael Bommarito; +Cc: Marcel Holtmann, linux-bluetooth, linux-kernel
In-Reply-To: <CAJJ9bXxCMVzVASz64obn78Ob2CDKBZX3r4B5iE_=+hbnwXDirQ@mail.gmail.com>
Hi Michael,
On Wed, Apr 22, 2026 at 11:09 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> On Wed, Apr 22, 2026 at 10:55 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > We might need a lock in order to access the session->conn:
>
> This one is a little easier than the other txwin_size issue in terms
> of blast radius.
>
> What pattern would you prefer here?
>
> Option 1, smaller but ordering questions: hold the semaphore across
> check and use like this:
>
> down_read(&hidp_session_sem);
> if (session->conn)
> l2cap_unregister_user(session->conn, &session->user);
> up_read(&hidp_session_sem)
>
>
> Option 2, more correct but more cycles: snapshot the conn and use outside
>
> down_read(&hidp_session_sem);
> conn = session->conn;
> if (conn)
> l2cap_conn_get(conn);
> up_read(&hidp_session_sem);
> if (conn) {
> l2cap_unregister_user(conn, &session->user);
> l2cap_conn_put(conn);
> }
Neither seems completely correct, in my opinion. I guess we want to
use option 2 but set the session->conn to NULL since it will call
l2cap_unregister_user.
> Thanks,
> Mike Bommarito
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: HIDP: guard session->conn in hidp_connection_del
From: Pauli Virtanen @ 2026-04-22 15:48 UTC (permalink / raw)
To: Michael Bommarito, Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel
In-Reply-To: <CAJJ9bXxCMVzVASz64obn78Ob2CDKBZX3r4B5iE_=+hbnwXDirQ@mail.gmail.com>
Hi,
ke, 2026-04-22 kello 11:09 -0400, Michael Bommarito kirjoitti:
> On Wed, Apr 22, 2026 at 10:55 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > We might need a lock in order to access the session->conn:
>
> This one is a little easier than the other txwin_size issue in terms
> of blast radius.
>
> What pattern would you prefer here?
>
> Option 1, smaller but ordering questions: hold the semaphore across
> check and use like this:
>
> down_read(&hidp_session_sem);
> if (session->conn)
> l2cap_unregister_user(session->conn, &session->user);
> up_read(&hidp_session_sem)
>
>
> Option 2, more correct but more cycles: snapshot the conn and use outside
>
> down_read(&hidp_session_sem);
> conn = session->conn;
> if (conn)
> l2cap_conn_get(conn);
> up_read(&hidp_session_sem);
> if (conn) {
> l2cap_unregister_user(conn, &session->user);
> l2cap_conn_put(conn);
> }
I'm not sure now (would need to rethink it through), but one probably
should check if dbf666e4fc9b is needed or whether 752a6c9596d alone
would be enough to address the original issue.
--
Pauli Virtanen
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-22 15:43 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1081856
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-22 15:43 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1082082
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] e4a8b6: input: Fix checking LE bonding on HIDP
From: Luiz Augusto von Dentz @ 2026-04-22 15:43 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1084336
Home: https://github.com/bluez/bluez
Commit: e4a8b629ca08b64fc1ae7371299935706a961d53
https://github.com/bluez/bluez/commit/e4a8b629ca08b64fc1ae7371299935706a961d53
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-04-22 (Wed, 22 Apr 2026)
Changed paths:
M profiles/input/device.c
Log Message:
-----------
input: Fix checking LE bonding on HIDP
HIDP is classic only, LE uses HOG, so there is no point in checking the
bonding with the address type which in case the device supports
dual-mode will map to LE random/public address.
Fixes: https://github.com/bluez/bluez/issues/2034
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH] Bluetooth: RFCOMM: require a credit byte before consuming it
From: Luiz Augusto von Dentz @ 2026-04-22 15:15 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Marcel Holtmann, Kees Cook, Jakub Kicinski, Bastien Nocera,
Thomas Gleixner, Ingo Molnar, linux-bluetooth, linux-kernel,
stable
In-Reply-To: <20260417073446.95494-1-pengpeng@iscas.ac.cn>
Hi Pengpeng,
On Fri, Apr 17, 2026 at 3:35 AM Pengpeng Hou <pengpeng@iscas.ac.cn> wrote:
>
> rfcomm_recv_data() treats the first payload byte as a credit field when
> the UIH frame carries PF and credit-based flow control is enabled.
>
> After the header has been stripped, the code does not re-check that the
> frame still has at least one payload byte before dereferencing skb->data.
> A malformed short frame can therefore trigger an out-of-bounds read.
>
> Drop the frame if the optional credit byte is not present.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> net/bluetooth/rfcomm/core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 611a9a94151e..964a78d473cc 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1715,6 +1715,9 @@ static int rfcomm_recv_data(struct rfcomm_session *s, u8 dlci, int pf, struct sk
> }
>
> if (pf && d->cfc) {
> + if (!skb->len)
> + goto drop;
We can probably use skb_pull_data below, which checks skb->len.
> u8 credits = *(u8 *) skb->data; skb_pull(skb, 1);
>
> d->tx_credits += credits;
> --
> 2.50.1 (Apple Git-155)
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v2 1/2] Bluetooth: L2CAP: handle zero txwin_size in ERTM RFC option
From: Michael Bommarito @ 2026-04-22 15:11 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Mat Martineau, Hyunwoo Kim, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <CABBYNZK+o0wwOvjoz9w0ju4SoXpt6PM1xQwXU6OozVJLstWMGw@mail.gmail.com>
On Wed, Apr 22, 2026 at 11:09 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> 100-200 is not too bad though, if there are splits in, let's say, 5
> changes that seem doable, especially now that we can sashiko review it
> and point out if we are missing something. Another approach would be
> to leave the pre-existing issues to be fixed in a separate set.
OK, if you're down with a bigger blast radius, I'll go through and put
together a bigger patch set so we just fix it instead of deferring.
Might be a few days, I need to block out more time to diagram the
state model and conditions here given my lack of familiarity. Thanks
for your patience
Thanks,
Mike Bommarito
^ permalink raw reply
* Re: Bluetooth: Use AES-CMAC library API
From: Luiz Augusto von Dentz @ 2026-04-22 15:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: ebiggers
In-Reply-To: <69e81184.050a0220.343b8b.d048@mx.google.com>
Hi Eric,
On Tue, Apr 21, 2026 at 8:10 PM <bluez.test.bot@gmail.com> wrote:
>
> This is automated email and please do not reply to this email!
>
> Dear submitter,
>
> Thank you for submitting the patches to the linux bluetooth mailing list.
> This is a CI test results with your patch series:
> PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1084071
>
> ---Test result---
>
> Test Summary:
> CheckPatch PASS 1.56 seconds
> GitLint PASS 0.49 seconds
> SubjectPrefix PASS 0.17 seconds
> BuildKernel FAIL 20.93 seconds
> CheckAllWarning FAIL 23.01 seconds
> CheckSparse FAIL 22.09 seconds
> BuildKernel32 FAIL 20.31 seconds
> TestRunnerSetup FAIL 488.99 seconds
> TestRunner_l2cap-tester FAIL 0.11 seconds
> TestRunner_iso-tester FAIL 0.11 seconds
> TestRunner_bnep-tester FAIL 0.53 seconds
> TestRunner_mgmt-tester FAIL 0.11 seconds
> TestRunner_rfcomm-tester FAIL 0.11 seconds
> TestRunner_sco-tester FAIL 0.11 seconds
> TestRunner_ioctl-tester FAIL 0.11 seconds
> TestRunner_mesh-tester FAIL 0.11 seconds
> TestRunner_smp-tester FAIL 0.10 seconds
> TestRunner_userchan-tester FAIL 0.10 seconds
> TestRunner_6lowpan-tester FAIL 0.11 seconds
> IncrementalBuild FAIL 26.35 seconds
>
> Details
> ##############################
> Test: BuildKernel - FAIL
> Desc: Build Kernel for Bluetooth
> Output:
>
> net/bluetooth/smp.c:25:10: fatal error: crypto/aes-cbc-macs.h: No such file or directory
> 25 | #include <crypto/aes-cbc-macs.h>
> | ^~~~~~~~~~~~~~~~~~~~~~~
I guess this is expected since rc1 wasn't tagged yet, right? In that
case we will probably need to rebase once rc1 is tagged to integrate
these changes.
^ permalink raw reply
* Re: [PATCH] Bluetooth: HIDP: guard session->conn in hidp_connection_del
From: Michael Bommarito @ 2026-04-22 15:09 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Marcel Holtmann, linux-bluetooth, linux-kernel
In-Reply-To: <CABBYNZJu6bGZadWc10g=ZJPHoDZ_RKDosCgasow3oRpQchYZvw@mail.gmail.com>
On Wed, Apr 22, 2026 at 10:55 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> We might need a lock in order to access the session->conn:
This one is a little easier than the other txwin_size issue in terms
of blast radius.
What pattern would you prefer here?
Option 1, smaller but ordering questions: hold the semaphore across
check and use like this:
down_read(&hidp_session_sem);
if (session->conn)
l2cap_unregister_user(session->conn, &session->user);
up_read(&hidp_session_sem)
Option 2, more correct but more cycles: snapshot the conn and use outside
down_read(&hidp_session_sem);
conn = session->conn;
if (conn)
l2cap_conn_get(conn);
up_read(&hidp_session_sem);
if (conn) {
l2cap_unregister_user(conn, &session->user);
l2cap_conn_put(conn);
}
Thanks,
Mike Bommarito
^ permalink raw reply
* Re: [PATCH v2 1/2] Bluetooth: L2CAP: handle zero txwin_size in ERTM RFC option
From: Luiz Augusto von Dentz @ 2026-04-22 15:08 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, Mat Martineau, Hyunwoo Kim, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <CAJJ9bXy8CVjC4xG0zBcxi9xtiep33-uRGSysL1Q3FiqCN7Rt0w@mail.gmail.com>
Hi Michael,
On Wed, Apr 22, 2026 at 10:58 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> On Wed, Apr 22, 2026 at 10:44 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > This seems to be going sideways:
> >
> > https://sashiko.dev/#/patchset/CABBYNZ%2Bf3pur4cSsanQ1kvv-yORp2E0qmVLt9si_%2BFnnJup4Ng%40mail.gmail.com
> >
> > Patch 2/2 seems totally broken.
>
> Yeah, not a great turn. I am struggling to figure out where to move
> some of these parts and where to put the guards without touching too
> much. As Sashiko pointed out, there are some preexisting bugs or spec
> questions that I don't feel like I should be touching unless we expand
> this to more of a cleanup + hardening patch set.
>
> If we break this down, there are now ~5 different issues in
> adjacent/connected spots:
>
> Ones I was trying to hit or introduced:
> 1. Zero txwin_size in inbound CONFIG_REQ (ERTM RFC) - original bug.
> Need to balance normalization with spec.
> 2. Repeated CONFIG_RSP re-running l2cap_ertm_init in BT_CONNECTED -
> original v2 2/2 target. We need the guard somewhere safe under the
> state model.
> 3. Zero txwin_size from userspace setsockopt - original v2 1/2 hunk in
> l2cap_sock.c.
>
> Pre-existing issues:
> 3. STREAMING -> ERTM mode switch via late CONF_RSP - pre-existing.
> 4. l2cap_sock_setsockopt_old locking - pre-existing.
>
> It feels like the safe solution is probably going to be at least +100
> or 200 by the time it's done and more than just a hardening patch. I
> can take a spin at it, but I will probably be slower and more
> bug-prone than someone else. No pride of ownership here. Just let me
> know if you want to take the fix over or let me try again
100-200 is not too bad though, if there are splits in, let's say, 5
changes that seem doable, especially now that we can sashiko review it
and point out if we are missing something. Another approach would be
to leave the pre-existing issues to be fixed in a separate set.
> Thanks,
> MIke Bommarito
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH BlueZ v1] input: Fix checking LE bonding on HIDP
From: Luiz Augusto von Dentz @ 2026-04-22 15:03 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
HIDP is classic only, LE uses HOG, so there is no point in checking the
bonding with the address type which in case the device supports
dual-mode will map to LE random/public address.
Fixes: https://github.com/bluez/bluez/issues/2034
---
profiles/input/device.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/profiles/input/device.c b/profiles/input/device.c
index 6bdc5ee3aaf3..5b1be2b169f3 100644
--- a/profiles/input/device.c
+++ b/profiles/input/device.c
@@ -127,8 +127,8 @@ static int connection_disconnect(struct input_device *idev, uint32_t flags);
static bool input_device_bonded(struct input_device *idev)
{
- return device_is_bonded(idev->device,
- btd_device_get_bdaddr_type(idev->device));
+ /* HIDP is classic only; so consider it bonded if BDADDR_BREDR is */
+ return device_is_bonded(idev->device, BDADDR_BREDR);
}
static void input_device_free(struct input_device *idev)
@@ -172,8 +172,8 @@ static void input_device_free(struct input_device *idev)
static void virtual_cable_unplug(struct input_device *idev)
{
- device_remove_bonding(idev->device,
- btd_device_get_bdaddr_type(idev->device));
+ /* HIDP is classic only; so only remove BDADDR_BREDR bonding */
+ device_remove_bonding(idev->device, BDADDR_BREDR);
idev->virtual_cable_unplug = false;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH BlueZ v1] input: Fix checking LE bonding on HIDP
From: Luiz Augusto von Dentz @ 2026-04-22 14:58 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <93591251ab13408ba014fff8b9bcfc171893e232.camel@hadess.net>
Hi Bastien,
On Wed, Apr 22, 2026 at 4:01 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Tue, 2026-04-21 at 16:22 -0400, Luiz Augusto von Dentz wrote:
> > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> >
> > HIDP is classic only, LE uses HOG, so there is no point in checking
> > the
> > bonding with the address type which in case the device supports
> > dual-mode will map to LE random/public address.
> >
> > Fixes: https://github.com/bluez/bluez/issues/2034
> > ---
> > profiles/input/device.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/profiles/input/device.c b/profiles/input/device.c
> > index 6bdc5ee3aaf3..0ee6988c4e90 100644
> > --- a/profiles/input/device.c
> > +++ b/profiles/input/device.c
> > @@ -127,8 +127,7 @@ static int connection_disconnect(struct
> > input_device *idev, uint32_t flags);
> >
> > static bool input_device_bonded(struct input_device *idev)
> > {
> > - return device_is_bonded(idev->device,
> > - btd_device_get_bdaddr_type(idev-
> > >device));
> > + return device_is_bonded(idev->device, BDADDR_BREDR);
>
> Do we want to do the same in virtual_cable_unplug() in that same file?
Yep.
> Do we also want to apply this to hog_accept() with BDADDR_LE in
> profiles/input/hog.c ?
Not really. In the case of LE you really need to specify the address
type since there are multiple options: random versus public.
> > }
> >
> > static void input_device_free(struct input_device *idev)
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v2 1/2] Bluetooth: L2CAP: handle zero txwin_size in ERTM RFC option
From: Michael Bommarito @ 2026-04-22 14:58 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Mat Martineau, Hyunwoo Kim, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <CABBYNZKS5Prm+BTkpdPgArgODTEDgHXLjecfux=3ZW0r2x=UXw@mail.gmail.com>
On Wed, Apr 22, 2026 at 10:44 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> This seems to be going sideways:
>
> https://sashiko.dev/#/patchset/CABBYNZ%2Bf3pur4cSsanQ1kvv-yORp2E0qmVLt9si_%2BFnnJup4Ng%40mail.gmail.com
>
> Patch 2/2 seems totally broken.
Yeah, not a great turn. I am struggling to figure out where to move
some of these parts and where to put the guards without touching too
much. As Sashiko pointed out, there are some preexisting bugs or spec
questions that I don't feel like I should be touching unless we expand
this to more of a cleanup + hardening patch set.
If we break this down, there are now ~5 different issues in
adjacent/connected spots:
Ones I was trying to hit or introduced:
1. Zero txwin_size in inbound CONFIG_REQ (ERTM RFC) - original bug.
Need to balance normalization with spec.
2. Repeated CONFIG_RSP re-running l2cap_ertm_init in BT_CONNECTED -
original v2 2/2 target. We need the guard somewhere safe under the
state model.
3. Zero txwin_size from userspace setsockopt - original v2 1/2 hunk in
l2cap_sock.c.
Pre-existing issues:
3. STREAMING -> ERTM mode switch via late CONF_RSP - pre-existing.
4. l2cap_sock_setsockopt_old locking - pre-existing.
It feels like the safe solution is probably going to be at least +100
or 200 by the time it's done and more than just a hardening patch. I
can take a spin at it, but I will probably be slower and more
bug-prone than someone else. No pride of ownership here. Just let me
know if you want to take the fix over or let me try again
Thanks,
MIke Bommarito
^ permalink raw reply
* Re: [PATCH] Bluetooth: HIDP: guard session->conn in hidp_connection_del
From: Luiz Augusto von Dentz @ 2026-04-22 14:55 UTC (permalink / raw)
To: Michael Bommarito; +Cc: Marcel Holtmann, linux-bluetooth, linux-kernel
In-Reply-To: <20260422011437.176643-1-michael.bommarito@gmail.com>
Hi Michael,
On Tue, Apr 21, 2026 at 9:14 PM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> commit dbf666e4fc9b ("Bluetooth: HIDP: Fix possible UAF") changed
> hidp_session_remove() to drop the L2CAP reference and set
> session->conn = NULL once the session is considered removed, and
> added an if (session->conn) guard around the l2cap_unregister_user()
> call at the kthread-exit site in hidp_session_thread().
>
> The sibling call site in hidp_connection_del() still invokes
> l2cap_unregister_user(session->conn, &session->user) unconditionally.
> hidp_session_find() takes the session refcount under
> down_read(&hidp_session_sem) and returns; between the find() and the
> call at :1421, hidp_session_remove() can run on another thread
> (driven by the remote peer disconnecting or local teardown), take
> down_write(&hidp_session_sem), set session->conn to NULL, and return.
> The HIDPCONNDEL ioctl path then dereferences a NULL l2cap_conn inside
> l2cap_unregister_user(), which acquires conn->lock without a NULL
> check. Result: kernel NULL-pointer dereference.
>
> Apply the same if (session->conn) guard used at the twin site. No
> functional change when session->conn is non-NULL.
>
> Discovery and verification:
>
> - Found via static audit of every session->conn read in hidp/core.c
> after the referenced commit landed. The other reads are safe
> (creation-time in hidp_session_dev_init, already-guarded in
> session_free / hidp_session_thread / hidp_session_remove; the other
> hidp_session_find callers do not touch session->conn at all), so
> :1421 is the only remaining unguarded site.
> - Runtime A/B confirmed in UML with CONFIG_BT_HIDP=y + CONFIG_KASAN=y:
> a late_initcall stub that injects a fake hidp_session with
> conn=NULL into hidp_session_list and invokes hidp_connection_del()
> panics on the pre-fix tree at __mutex_lock from
> l2cap_unregister_user+0x2d, and returns cleanly on the post-fix
> tree with the new guard short-circuiting before the deref.
>
> Fixes: dbf666e4fc9b ("Bluetooth: HIDP: Fix possible UAF")
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Assisted-by: Claude:claude-opus-4-7
> ---
> net/bluetooth/hidp/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index 7bcf8c5ceaee..9192efd1b156 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -1417,7 +1417,7 @@ int hidp_connection_del(struct hidp_conndel_req *req)
> HIDP_TRANS_HID_CONTROL |
> HIDP_CTRL_VIRTUAL_CABLE_UNPLUG,
> NULL, 0);
> - else
> + else if (session->conn)
> l2cap_unregister_user(session->conn, &session->user);
>
> hidp_session_put(session);
> --
> 2.53.0
We might need a lock in order to access the session->conn:
https://sashiko.dev/#/patchset/20260422011437.176643-1-michael.bommarito%40gmail.com
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v2 1/2] Bluetooth: L2CAP: handle zero txwin_size in ERTM RFC option
From: Luiz Augusto von Dentz @ 2026-04-22 14:44 UTC (permalink / raw)
To: Michael Bommarito
Cc: Marcel Holtmann, Mat Martineau, Hyunwoo Kim, linux-bluetooth,
linux-kernel, stable
In-Reply-To: <20260421135639.3185653-2-michael.bommarito@gmail.com>
Hi Michael,
On Tue, Apr 21, 2026 at 9:56 AM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> Peer-supplied ERTM RFC txwin_size = 0 can still propagate into the
> ERTM transmit-window state, and the same invalid value can be
> introduced locally through L2CAP_OPTIONS. In the request path that zero
> reaches l2cap_seq_list_init(..., 0); in the response path it can shrink
> ack_win to 0 and leave ERTM sequencing in a nonsensical state.
>
> Normalize zero tx window values back to L2CAP_DEFAULT_TX_WINDOW
> wherever they enter the ERTM state machine: local socket options,
> outgoing tx_win setup, incoming config requests, and config-response
> parsing. Also make l2cap_seq_list_free() clear its metadata after kfree
> so an init failure after freeing srej_list cannot be freed a second time
> during later channel teardown.
>
> Fixes: 3c588192b5e5 ("Bluetooth: Add the l2cap_seq_list structure for tracking frames")
> Cc: stable@vger.kernel.org
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Assisted-by: Claude:claude-opus-4-7
> ---
> Changes in v2:
> - drop the v1 `l2cap_seq_list_init(size == 0) -> -EINVAL` approach
> and instead normalize zero tx window values at the socket /
> request / response inputs
> - clamp the local `L2CAP_OPTIONS` txwin_size = 0 case back to
> `L2CAP_DEFAULT_TX_WINDOW`
> - make `l2cap_seq_list_free()` clear its metadata after `kfree()` so
> later teardown cannot trip over a previously freed list
> - split the repeated `CONFIG_RSP` ERTM re-init fix into patch 2
>
> net/bluetooth/l2cap_core.c | 23 +++++++++++++++++++----
> net/bluetooth/l2cap_sock.c | 3 +++
> 2 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 95c65fece39b..7ffafd117817 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -345,6 +345,10 @@ static int l2cap_seq_list_init(struct l2cap_seq_list *seq_list, u16 size)
> static inline void l2cap_seq_list_free(struct l2cap_seq_list *seq_list)
> {
> kfree(seq_list->list);
> + seq_list->list = NULL;
> + seq_list->mask = 0;
> + seq_list->head = L2CAP_SEQ_LIST_CLEAR;
> + seq_list->tail = L2CAP_SEQ_LIST_CLEAR;
> }
>
> static inline bool l2cap_seq_list_contains(struct l2cap_seq_list *seq_list,
> @@ -3234,8 +3238,15 @@ static void __l2cap_set_ertm_timeouts(struct l2cap_chan *chan,
> rfc->monitor_timeout = cpu_to_le16(L2CAP_DEFAULT_MONITOR_TO);
> }
>
> +static inline u16 l2cap_txwin_default(u16 txwin)
> +{
> + return txwin ? txwin : L2CAP_DEFAULT_TX_WINDOW;
> +}
> +
> static inline void l2cap_txwin_setup(struct l2cap_chan *chan)
> {
> + chan->tx_win = l2cap_txwin_default(chan->tx_win);
> +
> if (chan->tx_win > L2CAP_DEFAULT_TX_WINDOW &&
> __l2cap_ews_supported(chan->conn)) {
> /* use extended control field */
> @@ -3593,6 +3604,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
> break;
>
> case L2CAP_MODE_ERTM:
> + rfc.txwin_size = l2cap_txwin_default(rfc.txwin_size);
> +
> if (!test_bit(CONF_EWS_RECV, &chan->conf_state))
> chan->remote_tx_win = rfc.txwin_size;
> else
> @@ -3715,7 +3728,8 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
> case L2CAP_CONF_EWS:
> if (olen != 2)
> break;
> - chan->ack_win = min_t(u16, val, chan->ack_win);
> + chan->ack_win = min_t(u16, l2cap_txwin_default(val),
> + chan->ack_win);
> l2cap_add_conf_opt(&ptr, L2CAP_CONF_EWS, 2,
> chan->tx_win, endptr - ptr);
> break;
> @@ -3756,7 +3770,7 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
> chan->mps = le16_to_cpu(rfc.max_pdu_size);
> if (!test_bit(FLAG_EXT_CTRL, &chan->flags))
> chan->ack_win = min_t(u16, chan->ack_win,
> - rfc.txwin_size);
> + l2cap_txwin_default(rfc.txwin_size));
>
> if (test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
> chan->local_msdu = le16_to_cpu(efs.msdu);
> @@ -3970,10 +3984,11 @@ static void l2cap_conf_rfc_get(struct l2cap_chan *chan, void *rsp, int len)
> chan->monitor_timeout = le16_to_cpu(rfc.monitor_timeout);
> chan->mps = le16_to_cpu(rfc.max_pdu_size);
> if (test_bit(FLAG_EXT_CTRL, &chan->flags))
> - chan->ack_win = min_t(u16, chan->ack_win, txwin_ext);
> + chan->ack_win = min_t(u16, chan->ack_win,
> + l2cap_txwin_default(txwin_ext));
> else
> chan->ack_win = min_t(u16, chan->ack_win,
> - rfc.txwin_size);
> + l2cap_txwin_default(rfc.txwin_size));
> break;
> case L2CAP_MODE_STREAMING:
> chan->mps = le16_to_cpu(rfc.max_pdu_size);
> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> index 71e8c1b45bce..3b53e967bf40 100644
> --- a/net/bluetooth/l2cap_sock.c
> +++ b/net/bluetooth/l2cap_sock.c
> @@ -765,6 +765,9 @@ static int l2cap_sock_setsockopt_old(struct socket *sock, int optname,
> break;
> }
>
> + if (!opts.txwin_size)
> + opts.txwin_size = L2CAP_DEFAULT_TX_WINDOW;
> +
> if (!l2cap_valid_mtu(chan, opts.imtu)) {
> err = -EINVAL;
> break;
> --
> 2.53.0
This seems to be going sideways:
https://sashiko.dev/#/patchset/CABBYNZ%2Bf3pur4cSsanQ1kvv-yORp2E0qmVLt9si_%2BFnnJup4Ng%40mail.gmail.com
Patch 2/2 seems totally broken.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [syzbot] [bluetooth] KASAN: slab-use-after-free Read in process_one_work (2)
From: syzbot @ 2026-04-22 13:34 UTC (permalink / raw)
To: bp, dave.hansen, hpa, linux-bluetooth, linux-kernel, luiz.dentz,
marcel, mingo, syzkaller-bugs, tglx, x86
Hello,
syzbot found the following issue on:
HEAD commit: c7275b05bc42 Add linux-next specific files for 20260417
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14aac1ba580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ac861e8185149d86
dashboard link: https://syzkaller.appspot.com/bug?extid=b6a688ec97f423efb8ab
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/02c64cb49b64/disk-c7275b05.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2703650c5cda/vmlinux-c7275b05.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4a9b28b754f3/bzImage-c7275b05.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b6a688ec97f423efb8ab@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:166
Read of size 1 at addr ffff8880318ca330 by task kworker/1:8/10951
CPU: 1 UID: 0 PID: 10951 Comm: kworker/1:8 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Workqueue: events l2cap_chan_timeout
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
__kasan_check_byte+0x2a/0x40 mm/kasan/common.c:574
kasan_check_byte include/linux/kasan.h:402 [inline]
lock_acquire+0x84/0x350 kernel/locking/lockdep.c:5844
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:166
rt_mutex_slowunlock+0xb8/0x300 kernel/locking/rtmutex.c:1426
process_one_work+0x9a3/0x1710 kernel/workqueue.c:3312
process_scheduled_works kernel/workqueue.c:3403 [inline]
worker_thread+0xba8/0x11e0 kernel/workqueue.c:3489
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Allocated by task 60:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x3a6/0x690 mm/slub.c:5415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
l2cap_conn_add+0xaa/0x970 net/bluetooth/l2cap_core.c:7001
l2cap_connect_cfm+0x142/0x1560 net/bluetooth/l2cap_core.c:7378
hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]
hci_remote_features_evt+0x5b9/0x950 net/bluetooth/hci_event.c:3760
hci_event_func net/bluetooth/hci_event.c:7796 [inline]
hci_event_packet+0x6ab/0xef0 net/bluetooth/hci_event.c:7847
hci_rx_work+0x3ee/0x1040 net/bluetooth/hci_core.c:4077
process_one_work+0x9a3/0x1710 kernel/workqueue.c:3312
process_scheduled_works kernel/workqueue.c:3403 [inline]
worker_thread+0xba8/0x11e0 kernel/workqueue.c:3489
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 13989:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2689 [inline]
slab_free mm/slub.c:6246 [inline]
kfree+0x1c5/0x6c0 mm/slub.c:6561
hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline]
hci_conn_hash_flush+0x10d/0x260 net/bluetooth/hci_conn.c:2734
hci_dev_close_sync+0x821/0x10e0 net/bluetooth/hci_sync.c:5368
hci_dev_do_close net/bluetooth/hci_core.c:502 [inline]
hci_unregister_dev+0x21a/0x5a0 net/bluetooth/hci_core.c:2716
vhci_release+0x155/0x1b0 drivers/bluetooth/hci_vhci.c:690
__fput+0x461/0xa70 fs/file_table.c:510
task_work_run+0x1d9/0x270 kernel/task_work.c:233
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0x70f/0x22c0 kernel/exit.c:975
do_group_exit+0x21b/0x2d0 kernel/exit.c:1117
get_signal+0x1284/0x1330 kernel/signal.c:3037
arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x86/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
insert_work+0x3d/0x330 kernel/workqueue.c:2226
__queue_work+0xcfd/0x1010 kernel/workqueue.c:2381
call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1794 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x764/0x9f0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
handle_softirqs+0x1de/0x6d0 kernel/softirq.c:626
__do_softirq kernel/softirq.c:660 [inline]
run_ktimerd+0x69/0x100 kernel/softirq.c:1155
smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Second to last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
insert_work+0x3d/0x330 kernel/workqueue.c:2226
__queue_work+0xbdb/0x1010 kernel/workqueue.c:2385
queue_work_on+0x106/0x1d0 kernel/workqueue.c:2432
queue_work include/linux/workqueue.h:696 [inline]
l2cap_conn_ready net/bluetooth/l2cap_core.c:1660 [inline]
l2cap_connect_cfm+0x10f5/0x1560 net/bluetooth/l2cap_core.c:7419
hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]
hci_remote_features_evt+0x5b9/0x950 net/bluetooth/hci_event.c:3760
hci_event_func net/bluetooth/hci_event.c:7796 [inline]
hci_event_packet+0x6ab/0xef0 net/bluetooth/hci_event.c:7847
hci_rx_work+0x3ee/0x1040 net/bluetooth/hci_core.c:4077
process_one_work+0x9a3/0x1710 kernel/workqueue.c:3312
process_scheduled_works kernel/workqueue.c:3403 [inline]
worker_thread+0xba8/0x11e0 kernel/workqueue.c:3489
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff8880318ca000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 816 bytes inside of
freed 1024-byte region [ffff8880318ca000, ffff8880318ca400)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff8880318cf800 pfn:0x318c8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x80000000000240(workingset|head|node=0|zone=1)
page_type: f5(slab)
raw: 0080000000000240 ffff88813fe0fdc0 ffffea00007db010 ffffea0001ad2610
raw: ffff8880318cf800 000000080010000e 00000000f5000000 0000000000000000
head: 0080000000000240 ffff88813fe0fdc0 ffffea00007db010 ffffea0001ad2610
head: ffff8880318cf800 000000080010000e 00000000f5000000 0000000000000000
head: 0080000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid 1 (swapper/0), ts 17176054733, free_ts 0
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
prep_new_page mm/page_alloc.c:1866 [inline]
get_page_from_freelist+0x27d6/0x2850 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
alloc_slab_page mm/slub.c:3278 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3467
new_slab mm/slub.c:3525 [inline]
refill_objects+0x33c/0x3d0 mm/slub.c:7251
refill_sheaf mm/slub.c:2816 [inline]
__pcs_replace_empty_main+0x373/0x720 mm/slub.c:4651
alloc_from_pcs mm/slub.c:4749 [inline]
slab_alloc_node mm/slub.c:4883 [inline]
__kmalloc_cache_noprof+0x44e/0x690 mm/slub.c:5410
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
comedi_alloc_board_minor+0x57/0x530 drivers/comedi/comedi_fops.c:3510
comedi_init+0x109/0x1c0 drivers/comedi/comedi_fops.c:3664
do_one_initcall+0x250/0x870 init/main.c:1392
do_initcall_level+0x104/0x190 init/main.c:1454
do_initcalls+0x59/0xa0 init/main.c:1470
kernel_init_freeable+0x2a6/0x3e0 init/main.c:1703
kernel_init+0x1d/0x1d0 init/main.c:1593
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page_owner free stack trace missing
Memory state around the buggy address:
ffff8880318ca200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880318ca280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880318ca300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880318ca380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880318ca400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id
From: Andy Shevchenko @ 2026-04-22 12:44 UTC (permalink / raw)
To: Christian A. Ehrhardt
Cc: Uwe Kleine-König (The Capable Hub), Luiz Augusto von Dentz,
Ulf Hansson, Christian A. Ehrhardt, linux-mmc, Greg Kroah-Hartman,
Wolfram Sang, linux-kernel, Marcel Holtmann, linux-bluetooth,
Matthias Brugger, AngeloGioacchino Del Regno, linux-mediatek,
Ping-Ke Shih, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
Ryder Lee, Shayne Chen, Sean Wang, Brian Norris,
Francesco Dolcini
In-Reply-To: <aeipQfCYKjl006uM@cae.in-ulm.de>
On Wed, Apr 22, 2026 at 12:56:01PM +0200, Christian A. Ehrhardt wrote:
> On Wed, Apr 22, 2026 at 09:52:11AM +0300, Andy Shevchenko wrote:
> > > To be honest, with the involved void* this isn't really type-safe
> > > either, but at least the data keeps being a pointer which is really
> > > helpful on CHERI. FTR: The alternative would be to use uintptr_t instead
> > > of unsigned long, which also has proponents in the CHERI community and
> > > which is used in the current vendor patch stack.
> >
> > FWIW, Linus categorically told that it has to be no uintptr_t in the
> > Linux kernel.
>
> This is probably not the correct context to discuss this but
> I will point out that if/when CHERI support is added to the
> kernel we will need a way to distinguish between
> * A (fat) pointer converted to an integer type (in order to do
> integer arithmetic on the address) that might be converted back
> to a pointer in the future and
> * A plain address "extracted" from a fat pointer.
> Using `uintptr_t` for the former and `unsigned long` for the
> latter seems like a reasonable choice but there are certainly
> other options.
>
> Sorting out the difference between the two is a very large
> part of the diff required to port Linux (or in fact any piece
> of low-level software) to a CHERI system.
Right, whatever CHERI needs is has to be discussed with the project leader(s)
first. But thanks for giving more information on this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 06/12] power: sequencing: pcie-m2: Improve PCI device ID check
From: Konrad Dybcio @ 2026-04-22 12:17 UTC (permalink / raw)
To: manivannan.sadhasivam, Bartosz Golaszewski, Manivannan Sadhasivam,
Marcel Holtmann, Luiz Augusto von Dentz, Shuai Zhang
Cc: linux-pm, linux-kernel, linux-pci, linux-arm-msm, linux-bluetooth,
Wei Deng, Luiz Augusto von Dentz
In-Reply-To: <20260422-pwrseq-m2-bt-v1-6-720d02545a64@oss.qualcomm.com>
On 4/22/26 1:24 PM, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> Instead of hardcoding the PCI device check, use pci_match_id() to check for
> the known IDs using the pwrseq_m2_pci_ids[] array.
>
> This makes adding support for new devices easier.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: Fixes/improvements for the PCI M.2 power sequencing driver
From: bluez.test.bot @ 2026-04-22 11:39 UTC (permalink / raw)
To: linux-bluetooth, manivannan.sadhasivam
In-Reply-To: <20260422-pwrseq-m2-bt-v1-1-720d02545a64@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: drivers/power/sequencing/pwrseq-pcie-m2.c:121
error: drivers/power/sequencing/pwrseq-pcie-m2.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH 11/12] Bluetooth: hci_qca: Check whether the M.2 UART interface is fixed or not
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-22 11:24 UTC (permalink / raw)
To: Bartosz Golaszewski, Manivannan Sadhasivam, Marcel Holtmann,
Luiz Augusto von Dentz, Shuai Zhang
Cc: linux-pm, linux-kernel, linux-pci, linux-arm-msm, linux-bluetooth,
Wei Deng, Luiz Augusto von Dentz, Manivannan Sadhasivam
In-Reply-To: <20260422-pwrseq-m2-bt-v1-0-720d02545a64@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
In the M.2 connector, the UART interface is controlled through the
W_DISABLE2# signal. But the BT driver cannot know directly whether this
signal is available or not.
Hence, use the new pwrseq API 'pwrseq_is_fixed()' to check whether the UART
interface on the M.2 connector is fixed or controllable and set the
'bt_en_available' flag accordingly.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/bluetooth/hci_qca.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 3e71a72ea7c7..27e52b08ec47 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -2453,6 +2453,10 @@ static int qca_serdev_probe(struct serdev_device *serdev)
"uart");
if (IS_ERR(qcadev->bt_power->pwrseq))
return PTR_ERR(qcadev->bt_power->pwrseq);
+
+ if (pwrseq_is_fixed(qcadev->bt_power->pwrseq))
+ bt_en_available = false;
+
break;
}
--
2.51.0
^ permalink raw reply related
* [PATCH 06/12] power: sequencing: pcie-m2: Improve PCI device ID check
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-22 11:24 UTC (permalink / raw)
To: Bartosz Golaszewski, Manivannan Sadhasivam, Marcel Holtmann,
Luiz Augusto von Dentz, Shuai Zhang
Cc: linux-pm, linux-kernel, linux-pci, linux-arm-msm, linux-bluetooth,
Wei Deng, Luiz Augusto von Dentz, Manivannan Sadhasivam
In-Reply-To: <20260422-pwrseq-m2-bt-v1-0-720d02545a64@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Instead of hardcoding the PCI device check, use pci_match_id() to check for
the known IDs using the pwrseq_m2_pci_ids[] array.
This makes adding support for new devices easier.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/power/sequencing/pwrseq-pcie-m2.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index d4d246a30a97..bdc4391c87c9 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -351,6 +351,11 @@ static void pwrseq_pcie_m2_remove_serdev(struct pwrseq_pcie_m2_ctx *ctx,
mutex_unlock(&ctx->list_lock);
}
+static const struct pci_device_id pwrseq_m2_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1107) },
+ { } /* Sentinel */
+};
+
static int pwrseq_pcie_m2_notify(struct notifier_block *nb, unsigned long action,
void *data)
{
@@ -370,16 +375,14 @@ static int pwrseq_pcie_m2_notify(struct notifier_block *nb, unsigned long action
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
- /* Create serdev device for WCN7850 */
- if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107) {
+ if (pci_match_id(pwrseq_m2_pci_ids, pdev)) {
ret = pwrseq_pcie_m2_create_serdev(ctx, pdev);
if (ret)
return notifier_from_errno(ret);
}
break;
case BUS_NOTIFY_REMOVED_DEVICE:
- /* Destroy serdev device for WCN7850 */
- if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107)
+ if (pci_match_id(pwrseq_m2_pci_ids, pdev))
pwrseq_pcie_m2_remove_serdev(ctx, pdev);
break;
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox