* Re: [PATCH v2] Bluetooth: bnep: reject short frames before parsing
From: Luiz Augusto von Dentz @ 2026-05-18 21:39 UTC (permalink / raw)
To: Zhang Cen
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, zerocling0077,
2045gemini
In-Reply-To: <20260516004433.3199522-1-rollkingzzc@gmail.com>
Hi,
On Fri, May 15, 2026 at 8:44 PM Zhang Cen <rollkingzzc@gmail.com> wrote:
>
> An L2CAP peer can deliver an empty BNEP payload or a payload that contains
> only the outer type byte. bnep_rx_frame() currently reads the BNEP type
> byte and, for control packets, the control opcode before it proves that
> the skb contains those bytes. The BNEP_SETUP_CONN_REQ path can also read
> the setup size byte before that byte is present, and bnep_rx_control()
> dereferences the control opcode before checking that its control payload
> is non-empty.
>
> Reject empty skbs before reading the outer type byte, require a control
> opcode before parsing BNEP_CONTROL, require the setup size byte before
> using it, and make bnep_rx_control() fail zero-length control payloads.
>
> Validation reproduced this kernel report:
> KASAN slab-out-of-bounds in bnep_rx_frame()
> Read of size 1
> Call trace:
> dump_stack_lvl() (?:?)
> print_address_description() (mm/kasan/report.c:373)
> bnep_rx_frame() (net/bluetooth/bnep/core.c:306)
> print_report() (?:?)
> __virt_addr_valid() (?:?)
> srso_alias_return_thunk() (arch/x86/include/asm/nospec-branch.h:375)
> kasan_addr_to_slab() (mm/kasan/common.c:45)
> kasan_report() (?:?)
> process_one_work() (kernel/workqueue.c:3200)
> worker_thread() (?:?)
> __kthread_parkme() (kernel/kthread.c:259)
> kthread() (?:?)
> _raw_spin_unlock_irq() (kernel/locking/spinlock.c:204)
> ret_from_fork() (?:?)
> __switch_to() (?:?)
> ret_from_fork_asm() (?:?)
> kasan_save_stack() (mm/kasan/common.c:52)
> kasan_save_track() (mm/kasan/common.c:74)
> __kasan_kmalloc() (?:?)
> vpanic() (kernel/panic.c:576)
> panic() (?:?)
> preempt_schedule_common() (kernel/sched/core.c:7352)
> preempt_schedule_thunk() (?:?)
> end_report() (mm/kasan/report.c:219)
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Zhang Cen <rollkingzzc@gmail.com>
>
> ---
> diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
> index d44987d4515c..f5070bbd6b57 100644
> --- a/net/bluetooth/bnep/core.c
> +++ b/net/bluetooth/bnep/core.c
> @@ -208,9 +208,14 @@ static int bnep_ctrl_set_mcfilter(struct bnep_session *s, u8 *data, int len)
>
> static int bnep_rx_control(struct bnep_session *s, void *data, int len)
> {
> - u8 cmd = *(u8 *)data;
> + u8 cmd;
> int err = 0;
>
> + if (len < 1)
> + return -EILSEQ;
> +
> + cmd = *(u8 *)data;
> +
> data++;
> len--;
>
> @@ -303,14 +308,21 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
>
> dev->stats.rx_bytes += skb->len;
>
> + if (skb->len < 1)
> + goto badframe;
Lets stop using skb->len directly and just skb_pull_data and theck if
the return is NULL.
> type = *(u8 *) skb->data;
> skb_pull(skb, 1);
> - ctrl_type = *(u8 *)skb->data;
>
> if ((type & BNEP_TYPE_MASK) >= sizeof(__bnep_rx_hlen))
> goto badframe;
>
> if ((type & BNEP_TYPE_MASK) == BNEP_CONTROL) {
> + if (skb->len < 1)
> + goto badframe;
> +
> + ctrl_type = *(u8 *)skb->data;
> +
> if (bnep_rx_control(s, skb->data, skb->len) < 0) {
> dev->stats.tx_errors++;
> kfree_skb(skb);
> @@ -326,6 +338,9 @@ static int bnep_rx_frame(struct bnep_session *s, struct sk_buff *skb)
> switch (ctrl_type) {
> case BNEP_SETUP_CONN_REQ:
> /* Pull: ctrl type (1 b), len (1 b), data (len bytes) */
> + if (skb->len < 2)
> + goto badframe;
> +
> if (!skb_pull(skb, 2 + *(u8 *)(skb->data + 1) * 2))
> goto badframe;
> break;
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: rate-limit ECHO_RSP per signaling PDU
From: Luiz Augusto von Dentz @ 2026-05-18 21:37 UTC (permalink / raw)
To: Michael Bommarito
Cc: Muhammad Bilal, linux-bluetooth, linux-kernel, marcel,
johan.hedberg
In-Reply-To: <CABBYNZKA5SUNT8maNVzuAvxqaWYt-eU7F+h58oe8e==QsH53GA@mail.gmail.com>
Hi Michael,
On Mon, May 18, 2026 at 5:27 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Michael,
>
> On Sun, May 17, 2026 at 9:03 PM Michael Bommarito
> <michael.bommarito@gmail.com> wrote:
> >
> > On Sun, May 17, 2026 at 9:00 PM Muhammad Bilal <meatuni001@gmail.com> wrote:
> > > A response counter covering all outbound responses generated per PDU
> > > would close both paths. Something like:
> > >
> > > int resp_count = 0;
> > >
> > > /* in the error path: */
> > > if (err) {
> > > if (++resp_count <= L2CAP_SIG_ECHO_BURST) {
> > > BT_ERR("Wrong link type (%d)", err);
> > > l2cap_sig_send_rej(conn, cmd->ident);
> > > }
> > > continue;
> > > }
> > >
> > > /* existing echo path: */
> > > if (cmd->code == L2CAP_ECHO_REQ &&
> > > ++resp_count > L2CAP_SIG_ECHO_BURST) {
> > > skb_pull(skb, len);
> > > continue;
> > > }
> > >
> > > Using pr_warn_ratelimited() instead of BT_ERR() in the loop would
> > > also reduce log amplification independent of the skb path.
> >
> > Thanks, good catch on both! Luiz reminded me about
> > pr_warn_ratelimited before and I missed that again.
> >
> > I'll give others an opportunity to weigh in and then send an updated v2.
>
> Hmm, the spec does not have support limitation though, it just says:
>
> Implementations shall be able to handle the reception of multiple
> commands in an L2CAP packet sent over fixed channel CID 0x0001.
> [] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
>
> Perhaps we should define our Signalling MTU:
>
> Signaling MTU (MTUsig)
>
> The maximum size of command information that the L2CAP layer entity is
> capable of accepting. The MTUsig, refers to the signaling channel only
> and corresponds to the maximum size of a C-frame, omitting the size of
> the Basic L2CAP header. The MTUsig value of a peer is discovered when
> a C-frame that is too large is rejected by the peer.
>
> The minimum MTU seems to be 48, so we could probably use that as a
> limit for the overall packet. If the response exceeds this limit, we
> should reject it as recommended by the spec, but I think we need to
> reject the whole packet rather than the cmd CID.
Just confirmed, the packet as whole needs to be rejected:
When multiple commands are included in an L2CAP packet and the packet
exceeds the signaling MTU (MTUsig) of the receiver, a single
L2CAP_COMMAND_REJECT_RSP packet shall be sent in response. The
identifier shall match the first request command in the L2CAP packet.
If only responses are recognized, the packet shall be silently
discarded.
[] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-692db0dd-8ed5-693f-d300-4fd7af07e340
So we need to reject with L2CAP_REJ_MTU_EXCEEDED.
> > Thanks,
> > Mike
>
>
>
> --
> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: rate-limit ECHO_RSP per signaling PDU
From: Luiz Augusto von Dentz @ 2026-05-18 21:27 UTC (permalink / raw)
To: Michael Bommarito
Cc: Muhammad Bilal, linux-bluetooth, linux-kernel, marcel,
johan.hedberg
In-Reply-To: <CAJJ9bXz-Or+hQnCGYi9AD9+deQQHKewipU4-17CSgrS-4i-uEw@mail.gmail.com>
Hi Michael,
On Sun, May 17, 2026 at 9:03 PM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> On Sun, May 17, 2026 at 9:00 PM Muhammad Bilal <meatuni001@gmail.com> wrote:
> > A response counter covering all outbound responses generated per PDU
> > would close both paths. Something like:
> >
> > int resp_count = 0;
> >
> > /* in the error path: */
> > if (err) {
> > if (++resp_count <= L2CAP_SIG_ECHO_BURST) {
> > BT_ERR("Wrong link type (%d)", err);
> > l2cap_sig_send_rej(conn, cmd->ident);
> > }
> > continue;
> > }
> >
> > /* existing echo path: */
> > if (cmd->code == L2CAP_ECHO_REQ &&
> > ++resp_count > L2CAP_SIG_ECHO_BURST) {
> > skb_pull(skb, len);
> > continue;
> > }
> >
> > Using pr_warn_ratelimited() instead of BT_ERR() in the loop would
> > also reduce log amplification independent of the skb path.
>
> Thanks, good catch on both! Luiz reminded me about
> pr_warn_ratelimited before and I missed that again.
>
> I'll give others an opportunity to weigh in and then send an updated v2.
Hmm, the spec does not have support limitation though, it just says:
Implementations shall be able to handle the reception of multiple
commands in an L2CAP packet sent over fixed channel CID 0x0001.
[] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
Perhaps we should define our Signalling MTU:
Signaling MTU (MTUsig)
The maximum size of command information that the L2CAP layer entity is
capable of accepting. The MTUsig, refers to the signaling channel only
and corresponds to the maximum size of a C-frame, omitting the size of
the Basic L2CAP header. The MTUsig value of a peer is discovered when
a C-frame that is too large is rejected by the peer.
The minimum MTU seems to be 48, so we could probably use that as a
limit for the overall packet. If the response exceeds this limit, we
should reject it as recommended by the spec, but I think we need to
reject the whole packet rather than the cmd CID.
> Thanks,
> Mike
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v2] Bluetooth: btusb: Add Realtek RTL8852BE BT 0x04c5/0x1670 (Fujitsu)
From: Jaroslav Srba @ 2026-05-18 21:03 UTC (permalink / raw)
To: marcel, luiz.dentz; +Cc: linux-bluetooth, linux-kernel, jarys.cz
In-Reply-To: <20260518191654.615129-1-jarys.cz@gmail.com>
The Fujitsu LIFEBOOK E5512A ships with a Realtek RTL8852BE combo chip
whose Bluetooth half is exposed as a Fujitsu-rebranded USB device
0x04c5/0x1670. Without this entry in quirks_table, btusb binds via the
generic Bluetooth class match but never sets the BTUSB_REALTEK quirk,
so btrtl_setup_realtek() is never called and the rtl8852bu firmware
patch is never loaded. As a result HCI works (hci0 UP RUNNING), but
RF reception is non-functional: inquiry and LE scan find nothing and
pairing is impossible.
Other Fujitsu OEM rebrands of Realtek chips are already in quirks_table
(0x04c5/0x165c, 0x04c5/0x1675, 0x04c5/0x161f). Add 0x04c5/0x1670 in
the same "Realtek 8852BE Bluetooth devices" block, alongside 0x04c5/0x165c.
USB descriptors of the device:
Bus 001 Device 004: ID 04c5:1670 Fujitsu, Ltd Bluetooth Radio
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
iManufacturer 1 Realtek
iProduct 2 Bluetooth Radio
Tested on Fujitsu LIFEBOOK E5512A (Ryzen 7 PRO 5875U, Ubuntu 25.10,
kernel 6.17.0-29-generic). After the patch:
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_config.bin
Bluetooth: hci0: RTL: fw version 0x098b154b
Bluetooth: hci0: AOSP extensions version v1.00
Scanning, pairing and A2DP audio playback to BT headphones all work
after the firmware patch is loaded.
Signed-off-by: Jaroslav Srba <jarys.cz@gmail.com>
---
Changes in v2:
- Drop a long "RTL: examining hci_ver=..." line from the commit body
to satisfy checkpatch/gitlint 75-char limit. Chip identification is
conveyed by the firmware filename (rtl8852bu_fw.bin) and the
subsequent rom_version line, so no information is lost.
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7f5fce93d..93fcc02e0 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -543,6 +543,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x04c5, 0x165c), .driver_info = BTUSB_REALTEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x04c5, 0x1670), .driver_info = BTUSB_REALTEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x04ca, 0x4006), .driver_info = BTUSB_REALTEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0cb8, 0xc549), .driver_info = BTUSB_REALTEK |
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hci_core: Don't queue tx_work while draining workqueue
From: Luiz Augusto von Dentz @ 2026-05-18 20:48 UTC (permalink / raw)
To: Heitor Alves de Siqueira
Cc: Hillf Danton, Marcel Holtmann, Gustavo Padovan, linux-bluetooth,
linux-kernel, kernel-dev, syzkaller-bugs,
syzbot+97721dd81f792e838ba0
In-Reply-To: <DILWLB58NRY9.1AS5Z2W6EHAIG@igalia.com>
Hi Heitor,
On Mon, May 18, 2026 at 11:21 AM Heitor Alves de Siqueira
<halves@igalia.com> wrote:
>
> Hi Luiz,
>
> On Fri May 15, 2026 at 10:33 AM -03, Luiz Augusto von Dentz wrote:
> > Hi Heitor,
> >
> > On Thu, May 14, 2026 at 10:54 AM Heitor Alves de Siqueira
> > <halves@igalia.com> wrote:
> >>
> >> On Wed May 13, 2026 at 11:04 PM -03, Hillf Danton wrote:
> >> > On Wed, 13 May 2026 15:55:23 -0300 Heitor Alves de Siqueira wrote:
> >> >> Syzbot reported a warning when L2CAP calls queue_work() on the hdev
> >> >> workqueue while it's being drained. This can happen during device reset or
> >> >> close paths for hci_send_acl(), hci_send_sco() and hci_send_iso().
> >> >>
> >> >> The workqueue is drained in hci_dev_do_reset() and in hci_dev_close_sync():
> >> >> - hci_dev_close_sync() clears the HCI_UP bit before draining
> >> >> - hci_dev_do_reset() sets HCI_CMD_DRAIN_WORKQUEUE before draining
> >> >>
> >> >> Add these checks before queuing tx_work, and free the SKB if it's not
> >> >> queued for transmission.
> >> >>
> >> >> Fixes: 3eff45eaf817 ("Bluetooth: convert tx_task to workqueue")
> >> >> Reported-by: syzbot+97721dd81f792e838ba0@syzkaller.appspotmail.com
> >> >> Closes: https://syzkaller.appspot.com/bug?extid=97721dd81f792e838ba0
> >> >> Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com>
> >> >> ---
> >> >> net/bluetooth/hci_core.c | 18 ++++++++++++++++++
> >> >> 1 file changed, 18 insertions(+)
> >> >>
> >> >> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> >> >> index c46c1236ebfa..5d5f8ad7d1a8 100644
> >> >> --- a/net/bluetooth/hci_core.c
> >> >> +++ b/net/bluetooth/hci_core.c
> >> >> @@ -3278,6 +3278,12 @@ void hci_send_acl(struct hci_chan *chan, struct sk_buff *skb, __u16 flags)
> >> >>
> >> >> BT_DBG("%s chan %p flags 0x%4.4x", hdev->name, chan, flags);
> >> >>
> >> >> + if (!test_bit(HCI_UP, &hdev->flags) ||
> >> >> + hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE)) {
> >> >> + kfree_skb(skb);
> >> >> + return;
> >> >> + }
> >> >> +
> >> >> hci_queue_acl(chan, &chan->data_q, skb, flags);
> >> >>
> >> >> queue_work(hdev->workqueue, &hdev->tx_work);
> >> >>
> >> > What you add is not enough, go and see how HCI_CMD_DRAIN_WORKQUEUE is
> >> > checked in hci_cmd_work(), and in hci_dev_do_reset() for why.
> >>
> >> I see, I missed the RCU guards for the device flags. Sorry about that,
> >> I'll add them to v2.
> >> Thanks for the catch!
> >
> > Actually this whole thing might be because we try to clean the
> > workqueue without actually closing the hdev, so I suspect that if we
> > just remove all the code from hci_dev_do_reset with
> > hci_dev_do_close+hci_dev_do_open, it might work better and align with
> > how things work over the MGMT interface:
> >
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index c46c1236ebfa..6782bbc9b6a7 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -539,47 +539,13 @@ static int hci_dev_do_reset(struct hci_dev *hdev)
> >
> > hci_req_sync_lock(hdev);
> >
> > - /* Drop queues */
> > - skb_queue_purge(&hdev->rx_q);
> > - skb_queue_purge(&hdev->cmd_q);
> > -
> > - /* Cancel these to avoid queueing non-chained pending work */
> > - hci_dev_set_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE);
> > - /* Wait for
> > - *
> > - * if (!hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE))
> > - * queue_delayed_work(&hdev->{cmd,ncmd}_timer)
> > - *
> > - * inside RCU section to see the flag or complete scheduling.
> > - */
> > - synchronize_rcu();
> > - /* Explicitly cancel works in case scheduled after setting the flag. */
> > - cancel_delayed_work(&hdev->cmd_timer);
> > - cancel_delayed_work(&hdev->ncmd_timer);
> > -
> > - /* Avoid potential lockdep warnings from the *_flush() calls by
> > - * ensuring the workqueue is empty up front.
> > - */
> > - drain_workqueue(hdev->workqueue);
> > -
> > - hci_dev_lock(hdev);
> > - hci_inquiry_cache_flush(hdev);
> > - hci_conn_hash_flush(hdev);
> > - hci_dev_unlock(hdev);
> > -
> > - if (hdev->flush)
> > - hdev->flush(hdev);
> > -
> > - hci_dev_clear_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE);
> > -
> > - atomic_set(&hdev->cmd_cnt, 1);
> > - hdev->acl_cnt = 0;
> > - hdev->sco_cnt = 0;
> > - hdev->le_cnt = 0;
> > - hdev->iso_cnt = 0;
> > + ret = hci_dev_close_sync(hdev);
> > + if (ret)
> > + goto done;
> >
> > - ret = hci_reset_sync(hdev);
> > + ret = hci_dev_open_sync(hdev);
> >
> > +done:
> > hci_req_sync_unlock(hdev);
> > return ret;
> > }
> >
> > Seem to work here and as a side effect we get notified over the MGMT
> > when a user uses hciconfig hci0 reset:
> >
> > # tools/hciconfig hci0 reset
> > bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0006
> > bluetoothd[34]: src/adapter.c:new_settings_callback() Settings: 0x01fc0ac0
> > bluetoothd[34]: src/adapter.c:settings_changed() Changed settings: 0x00000001
> > bluetoothd[34]: src/adapter.c:settings_changed() Pending settings: 0x00000000
> > bluetoothd[34]: src/adapter.c:cancel_passive_scanning()
> > bluetoothd[34]: src/adapter.c:adapter_stop() adapter /org/bluez/hci0
> > has been disabled
> > bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0008
> > bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0006
> > bluetoothd[34]: src/adapter.c:new_settings_callback() Settings: 0x01fc0ac1
> > bluetoothd[34]: src/adapter.c:settings_changed() Changed settings: 0x00000001
> > bluetoothd[34]: src/adapter.c:settings_changed() Pending settings: 0x00000000
> > bluetoothd[34]: src/adapter.c:adapter_start() adapter /org/bluez/hci0
> > has been enabled
> > bluetoothd[34]: src/adapter.c:trigger_passive_scanning()
> > bluetoothd[34]: [signal] org.freedesktop.DBus.Properties.PropertiesChanged
>
> Thank you for the review, and for the suggestion! There seems to be a
> number of similar syzbot reports for the hdev workqueue, so maybe the
> close+open approach is a simpler solution indeed. I've originally
> considered implementing a wrapper/helper for workqueue submission in
> hci_core.c, but if we can eliminate the race condition altogether that'd
> be even better.
>
> My only concern is that there seem to be slight differences between
> what hci_dev_do_reset() does now and what we'd get with
> hci_dev_close_sync()+hci_dev_open_sync() (e.g. we wouldn't use
> HCI_CMD_DRAIN_WORKQUEUE anymore). Would this alternative approach be
> suitable for the stable kernels? And if not, do you think the checks
> from v1 would be appropriate, in that case?
I think, the HCI_Reset is a heavy hammer because it's a global reset.
Getting all the pieces to cooperate has been causing all sort of
issues, and in any case I think what hci_dev_do_reset does is simply
wrong or outdated; for instance it doesn't seem to affect LE, such as
cancelling scanning or advertising. This is likely because interfaces
like MGMT don't use it and require a power cycle to reset.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: SMP: add missing skb len check in smp_cmd_keypress_notify
From: Luiz Augusto von Dentz @ 2026-05-18 20:37 UTC (permalink / raw)
To: Muhammad Bilal
Cc: linux-bluetooth, linux-kernel, marcel, johan.hedberg, stable
In-Reply-To: <20260517145417.31910-1-meatuni001@gmail.com>
Hi Muhammad,
On Sun, May 17, 2026 at 10:55 AM Muhammad Bilal <meatuni001@gmail.com> wrote:
>
> smp_cmd_keypress_notify() accesses the received payload as
> struct smp_cmd_keypress_notify without verifying that skb->len
> contains enough data.
>
> smp_sig_channel() removes the opcode byte before dispatching to
> command handlers, so a SMP_CMD_KEYPRESS_NOTIFY packet without a
> payload leaves skb->len equal to zero on entry to the handler,
> causing a 1-byte out-of-bounds read from the heap.
>
> Add a length check before accessing the payload and return
> SMP_INVALID_PARAMS when the packet is too short, matching the
> pattern used by other SMP command handlers.
>
> Fixes: 1408bb6efb04 ("Bluetooth: Add dummy handler for LE SC keypress notification")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
> ---
> net/bluetooth/smp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
> index 98f1da4f5..4c98e2a3a 100644
> --- a/net/bluetooth/smp.c
> +++ b/net/bluetooth/smp.c
> @@ -2932,6 +2932,9 @@ static int smp_cmd_keypress_notify(struct l2cap_conn *conn,
> {
> struct smp_cmd_keypress_notify *kp = (void *) skb->data;
Perhaps we should stop assigning it directly and instead just use
`skb_pull_data`, which performs bounds checks on its own.
> + if (skb->len < sizeof(*kp))
> + return SMP_INVALID_PARAMS;
I suggested we add a bt_dev_warn_ratelimit with something like "Too
small packet: skb->len %u < %u" to make debugging easier.
> +
> bt_dev_dbg(conn->hcon->hdev, "value 0x%02x", kp->value);
>
> return 0;
> --
> 2.54.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: SMP: add missing skb len check in smp_cmd_keypress_notify
From: Paul Menzel @ 2026-05-18 20:29 UTC (permalink / raw)
To: Muhammad Bilal
Cc: linux-bluetooth, linux-kernel, marcel, luiz.dentz, johan.hedberg,
stable
In-Reply-To: <20260517190312.56076-1-meatuni001@gmail.com>
Dear Muhammad,
Am 17.05.26 um 21:03 schrieb Muhammad Bilal:
> There is no safe way to access kp->value in the truncated case, since
> the payload is not guaranteed to be present when skb->len < sizeof(*kp).
Indeed, you are right.
> If diagnostic information is still useful, only metadata can be logged:
>
> if (skb->len < sizeof(*kp)) {
> bt_dev_dbg(conn->hcon->hdev,
> "truncated keypress notify, len=%u",
> skb->len);
> return SMP_INVALID_PARAMS;
> }
>
> This keeps visibility into malformed packets without touching unvalidated
> memory. Happy to send a v2 if that looks good to you.
It looks good to me. Hopefully the maintainers agree.
Kind regards,
Paul
^ permalink raw reply
* RE: Bluetooth: btusb: Add Realtek RTL8852BE BT 0x04c5/0x1670 (Fujitsu)
From: bluez.test.bot @ 2026-05-18 20:28 UTC (permalink / raw)
To: linux-bluetooth, jarys.cz
In-Reply-To: <20260518191654.615129-1-jarys.cz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2305 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=1096820
---Test result---
Test Summary:
CheckPatch FAIL 0.53 seconds
GitLint FAIL 0.20 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.63 seconds
CheckAllWarning PASS 28.96 seconds
CheckSparse PASS 27.75 seconds
BuildKernel32 PASS 25.61 seconds
TestRunnerSetup PASS 565.04 seconds
IncrementalBuild PASS 25.41 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: btusb: Add Realtek RTL8852BE BT 0x04c5/0x1670 (Fujitsu)
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#123:
Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b lmp_ver=0b lmp_subver=8852
total: 0 errors, 1 warnings, 8 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14579881.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: btusb: Add Realtek RTL8852BE BT 0x04c5/0x1670 (Fujitsu)
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
28: B1 Line exceeds max length (84>80): " Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b lmp_ver=0b lmp_subver=8852"
https://github.com/bluez/bluetooth-next/pull/210
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-18 20:27 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
--- Comment #10 from Artem S. Tashkinov (aros@gmx.com) ---
Kernel developers seemingly aren't interested in fixing this in stable. The fix
has been submitted only for 7.1. At least that's what I've learned from someone
involved.
Arch Linux has already incorporated the fix. If you use a different distro,
report to their bug tracker.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH] Bluetooth: btusb: Add Realtek RTL8852BE BT 0x04c5/0x1670 (Fujitsu)
From: Jaroslav Srba @ 2026-05-18 19:16 UTC (permalink / raw)
To: marcel, luiz.dentz; +Cc: linux-bluetooth, linux-kernel, jarys.cz
The Fujitsu LIFEBOOK E5512A ships with a Realtek RTL8852BE combo chip
whose Bluetooth half is exposed as a Fujitsu-rebranded USB device
0x04c5/0x1670. Without this entry in quirks_table, btusb binds via the
generic Bluetooth class match but never sets the BTUSB_REALTEK quirk,
so btrtl_setup_realtek() is never called and the rtl8852bu firmware
patch is never loaded. As a result HCI works (hci0 UP RUNNING), but
RF reception is non-functional: inquiry and LE scan find nothing and
pairing is impossible.
Other Fujitsu OEM rebrands of Realtek chips are already in quirks_table
(0x04c5/0x165c, 0x04c5/0x1675, 0x04c5/0x161f). Add 0x04c5/0x1670 in
the same "Realtek 8852BE Bluetooth devices" block, alongside 0x04c5/0x165c.
USB descriptors of the device:
Bus 001 Device 004: ID 04c5:1670 Fujitsu, Ltd Bluetooth Radio
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
iManufacturer 1 Realtek
iProduct 2 Bluetooth Radio
Tested on Fujitsu LIFEBOOK E5512A (Ryzen 7 PRO 5875U, Ubuntu 25.10,
kernel 6.17.0-29-generic). After the patch:
Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b lmp_ver=0b lmp_subver=8852
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_config.bin
Bluetooth: hci0: RTL: fw version 0x098b154b
Bluetooth: hci0: AOSP extensions version v1.00
Scanning, pairing and A2DP audio playback to BT headphones all work
after the firmware patch is loaded.
Signed-off-by: Jaroslav Srba <jarys.cz@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7f5fce93d..93fcc02e0 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -543,6 +543,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x04c5, 0x165c), .driver_info = BTUSB_REALTEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x04c5, 0x1670), .driver_info = BTUSB_REALTEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x04ca, 0x4006), .driver_info = BTUSB_REALTEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0cb8, 0xc549), .driver_info = BTUSB_REALTEK |
--
2.51.0
^ permalink raw reply related
* [bluez/bluez]
From: BluezTestBot @ 2026-05-18 18:04 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1082814
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: [PATCH] Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
From: Luiz Augusto von Dentz @ 2026-05-18 16:39 UTC (permalink / raw)
To: Artem S. Tashkinov; +Cc: pav, linux-bluetooth, linux-mediatek, mark-yw.chen
In-Reply-To: <79571779-316d-4d7b-bbca-554328ec7dd6@gmx.com>
Hi Artem,
On Mon, May 18, 2026 at 12:33 PM Artem S. Tashkinov <aros@gmx.com> wrote:
>
> Hello,
>
> The kernel bug tracker already has half a dozen bug reports in regard to
> this regression, yet almost a week later I still don't see the fix
> pushed to stable.
>
> Please do.
No offense, but I recommend checking the list before generating this
kind of response:
https://patchwork.kernel.org/project/bluetooth/patch/20260514172340.1515042-1-luiz.dentz@gmail.com/
PR is in progress and will be merged in the next RC.
> Regards,
> Artem
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
From: Artem S. Tashkinov @ 2026-05-18 16:33 UTC (permalink / raw)
To: pav; +Cc: linux-bluetooth, linux-mediatek, mark-yw.chen
In-Reply-To: <770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi>
Hello,
The kernel bug tracker already has half a dozen bug reports in regard to
this regression, yet almost a week later I still don't see the fix
pushed to stable.
Please do.
Regards,
Artem
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_core: Don't queue tx_work while draining workqueue
From: Heitor Alves de Siqueira @ 2026-05-18 15:21 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Hillf Danton, Marcel Holtmann, Gustavo Padovan, linux-bluetooth,
linux-kernel, kernel-dev, syzkaller-bugs,
syzbot+97721dd81f792e838ba0
In-Reply-To: <CABBYNZKA3FsovfdWEeZYqFjjNCabjfa7uM48mq+r3G0PTb_JUg@mail.gmail.com>
Hi Luiz,
On Fri May 15, 2026 at 10:33 AM -03, Luiz Augusto von Dentz wrote:
> Hi Heitor,
>
> On Thu, May 14, 2026 at 10:54 AM Heitor Alves de Siqueira
> <halves@igalia.com> wrote:
>>
>> On Wed May 13, 2026 at 11:04 PM -03, Hillf Danton wrote:
>> > On Wed, 13 May 2026 15:55:23 -0300 Heitor Alves de Siqueira wrote:
>> >> Syzbot reported a warning when L2CAP calls queue_work() on the hdev
>> >> workqueue while it's being drained. This can happen during device reset or
>> >> close paths for hci_send_acl(), hci_send_sco() and hci_send_iso().
>> >>
>> >> The workqueue is drained in hci_dev_do_reset() and in hci_dev_close_sync():
>> >> - hci_dev_close_sync() clears the HCI_UP bit before draining
>> >> - hci_dev_do_reset() sets HCI_CMD_DRAIN_WORKQUEUE before draining
>> >>
>> >> Add these checks before queuing tx_work, and free the SKB if it's not
>> >> queued for transmission.
>> >>
>> >> Fixes: 3eff45eaf817 ("Bluetooth: convert tx_task to workqueue")
>> >> Reported-by: syzbot+97721dd81f792e838ba0@syzkaller.appspotmail.com
>> >> Closes: https://syzkaller.appspot.com/bug?extid=97721dd81f792e838ba0
>> >> Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com>
>> >> ---
>> >> net/bluetooth/hci_core.c | 18 ++++++++++++++++++
>> >> 1 file changed, 18 insertions(+)
>> >>
>> >> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
>> >> index c46c1236ebfa..5d5f8ad7d1a8 100644
>> >> --- a/net/bluetooth/hci_core.c
>> >> +++ b/net/bluetooth/hci_core.c
>> >> @@ -3278,6 +3278,12 @@ void hci_send_acl(struct hci_chan *chan, struct sk_buff *skb, __u16 flags)
>> >>
>> >> BT_DBG("%s chan %p flags 0x%4.4x", hdev->name, chan, flags);
>> >>
>> >> + if (!test_bit(HCI_UP, &hdev->flags) ||
>> >> + hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE)) {
>> >> + kfree_skb(skb);
>> >> + return;
>> >> + }
>> >> +
>> >> hci_queue_acl(chan, &chan->data_q, skb, flags);
>> >>
>> >> queue_work(hdev->workqueue, &hdev->tx_work);
>> >>
>> > What you add is not enough, go and see how HCI_CMD_DRAIN_WORKQUEUE is
>> > checked in hci_cmd_work(), and in hci_dev_do_reset() for why.
>>
>> I see, I missed the RCU guards for the device flags. Sorry about that,
>> I'll add them to v2.
>> Thanks for the catch!
>
> Actually this whole thing might be because we try to clean the
> workqueue without actually closing the hdev, so I suspect that if we
> just remove all the code from hci_dev_do_reset with
> hci_dev_do_close+hci_dev_do_open, it might work better and align with
> how things work over the MGMT interface:
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index c46c1236ebfa..6782bbc9b6a7 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -539,47 +539,13 @@ static int hci_dev_do_reset(struct hci_dev *hdev)
>
> hci_req_sync_lock(hdev);
>
> - /* Drop queues */
> - skb_queue_purge(&hdev->rx_q);
> - skb_queue_purge(&hdev->cmd_q);
> -
> - /* Cancel these to avoid queueing non-chained pending work */
> - hci_dev_set_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE);
> - /* Wait for
> - *
> - * if (!hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE))
> - * queue_delayed_work(&hdev->{cmd,ncmd}_timer)
> - *
> - * inside RCU section to see the flag or complete scheduling.
> - */
> - synchronize_rcu();
> - /* Explicitly cancel works in case scheduled after setting the flag. */
> - cancel_delayed_work(&hdev->cmd_timer);
> - cancel_delayed_work(&hdev->ncmd_timer);
> -
> - /* Avoid potential lockdep warnings from the *_flush() calls by
> - * ensuring the workqueue is empty up front.
> - */
> - drain_workqueue(hdev->workqueue);
> -
> - hci_dev_lock(hdev);
> - hci_inquiry_cache_flush(hdev);
> - hci_conn_hash_flush(hdev);
> - hci_dev_unlock(hdev);
> -
> - if (hdev->flush)
> - hdev->flush(hdev);
> -
> - hci_dev_clear_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE);
> -
> - atomic_set(&hdev->cmd_cnt, 1);
> - hdev->acl_cnt = 0;
> - hdev->sco_cnt = 0;
> - hdev->le_cnt = 0;
> - hdev->iso_cnt = 0;
> + ret = hci_dev_close_sync(hdev);
> + if (ret)
> + goto done;
>
> - ret = hci_reset_sync(hdev);
> + ret = hci_dev_open_sync(hdev);
>
> +done:
> hci_req_sync_unlock(hdev);
> return ret;
> }
>
> Seem to work here and as a side effect we get notified over the MGMT
> when a user uses hciconfig hci0 reset:
>
> # tools/hciconfig hci0 reset
> bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0006
> bluetoothd[34]: src/adapter.c:new_settings_callback() Settings: 0x01fc0ac0
> bluetoothd[34]: src/adapter.c:settings_changed() Changed settings: 0x00000001
> bluetoothd[34]: src/adapter.c:settings_changed() Pending settings: 0x00000000
> bluetoothd[34]: src/adapter.c:cancel_passive_scanning()
> bluetoothd[34]: src/adapter.c:adapter_stop() adapter /org/bluez/hci0
> has been disabled
> bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0008
> bluetoothd[34]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x0006
> bluetoothd[34]: src/adapter.c:new_settings_callback() Settings: 0x01fc0ac1
> bluetoothd[34]: src/adapter.c:settings_changed() Changed settings: 0x00000001
> bluetoothd[34]: src/adapter.c:settings_changed() Pending settings: 0x00000000
> bluetoothd[34]: src/adapter.c:adapter_start() adapter /org/bluez/hci0
> has been enabled
> bluetoothd[34]: src/adapter.c:trigger_passive_scanning()
> bluetoothd[34]: [signal] org.freedesktop.DBus.Properties.PropertiesChanged
Thank you for the review, and for the suggestion! There seems to be a
number of similar syzbot reports for the hdev workqueue, so maybe the
close+open approach is a simpler solution indeed. I've originally
considered implementing a wrapper/helper for workqueue submission in
hci_core.c, but if we can eliminate the race condition altogether that'd
be even better.
My only concern is that there seem to be slight differences between
what hci_dev_do_reset() does now and what we'd get with
hci_dev_close_sync()+hci_dev_open_sync() (e.g. we wouldn't use
HCI_CMD_DRAIN_WORKQUEUE anymore). Would this alternative approach be
suitable for the stable kernels? And if not, do you think the checks
from v1 would be appropriate, in that case?
^ permalink raw reply
* [Bug 221521] Bluetooth: btusb/mt7921 - Failed to send wmt func ctrl (-22) on MediaTek MT7921 combo adapter
From: bugzilla-daemon @ 2026-05-18 14:35 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221521-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221521
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sphinx-rift-sector@duck.com
--- Comment #9 from Artem S. Tashkinov (aros@gmx.com) ---
*** Bug 221539 has been marked as a duplicate of this bug. ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221539] MT7925 Bluetooth fails to initialize since kernel 7.0.8 — regression from 7.0.5
From: bugzilla-daemon @ 2026-05-18 14:35 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221539-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221539
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Artem S. Tashkinov (aros@gmx.com) ---
*** This bug has been marked as a duplicate of bug 221521 ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Bug 221539] MT7925 Bluetooth fails to initialize since kernel 7.0.8 — regression from 7.0.5
From: bugzilla-daemon @ 2026-05-18 10:12 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221539-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221539
kopper (niko.iskanius@duckpolice.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |niko.iskanius@duckpolice.co
| |m
--- Comment #1 from kopper (niko.iskanius@duckpolice.com) ---
Same behavior, when upgrading kernel on Debian Trixie (Stable) from 6.12.86 to
6.12.88.
**Hardware:**
- ASUS ROG STRIX B650E-I GAMING WIFI
- WiFi/BT chip: MediaTek MT7922
- PCIe ID: MEDIATEK Corp. MT7922 802.11ax
- BT interface: USB (hci0)
**Working kernel:** 6.12.86
**Broken kernel:** 6.12.88
**Firmware:** firmare-mediatek 20250410
(mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin)
**Distro:** Debian 13.5 (stable)
**Symptoms**
Identical to original report.
**dmesg (relevant lines):**
Bluetooth: Core ver 2.22
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20260224103448
Bluetooth: hci0: Failed to send wmt func ctrl (-22)
Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is
advertised, but not supported.
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: BNEP socket layer initialized
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* RE: [BlueZ,v2] device: fix inverted NULL check in gatt_db clone
From: bluez.test.bot @ 2026-05-18 9:48 UTC (permalink / raw)
To: linux-bluetooth, winter91
In-Reply-To: <tencent_017770C54B37BDA20BEEC119272E1AED0608@qq.com>
[-- Attachment #1: Type: text/plain, Size: 825 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=1096354
---Test result---
Test Summary:
CheckPatch PASS 0.48 seconds
GitLint PASS 0.65 seconds
BuildEll PASS 20.49 seconds
BluezMake PASS 638.98 seconds
CheckSmatch PASS 329.58 seconds
bluezmakeextell PASS 168.02 seconds
IncrementalBuild PASS 630.07 seconds
ScanBuild PASS 966.30 seconds
https://github.com/bluez/bluez/pull/2133
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-18 9:01 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1096236
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] 51f3a3: device: fix inverted NULL check in gatt_db clone
From: github-actions[bot] @ 2026-05-18 9:01 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1096354
Home: https://github.com/bluez/bluez
Commit: 51f3a3b221be978d726a4cfc74a30272a24e9e3c
https://github.com/bluez/bluez/commit/51f3a3b221be978d726a4cfc74a30272a24e9e3c
Author: Zhao Dongdong <zhaodongdong@kylinos.cn>
Date: 2026-05-18 (Mon, 18 May 2026)
Changed paths:
M src/device.c
Log Message:
-----------
device: fix inverted NULL check in gatt_db clone
gatt_db_clone() returns NULL on failure so the condition was inverted.
With the old check a successful clone (non-NULL) would return false and
skip swapping the device's GATT database, while a failure (NULL) would
fall through and dereference a NULL pointer a few lines below.
Fix by negating the condition: only bail out early if the clone failed;
proceed with the swap when the clone actually succeeds.
Fixes: cbe4144dea6f ("set: Attempt to use existing set gatt-db")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ v2] device: fix inverted NULL check in gatt_db clone
From: Zhao Dongdong @ 2026-05-18 6:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Zhao Dongdong
From: Zhao Dongdong <zhaodongdong@kylinos.cn>
gatt_db_clone() returns NULL on failure so the condition was inverted.
With the old check a successful clone (non-NULL) would return false and
skip swapping the device's GATT database, while a failure (NULL) would
fall through and dereference a NULL pointer a few lines below.
Fix by negating the condition: only bail out early if the clone failed;
proceed with the swap when the clone actually succeeds.
Fixes: cbe4144dea6f ("set: Attempt to use existing set gatt-db")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
---
src/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/device.c b/src/device.c
index 28515054c..bea893301 100644
--- a/src/device.c
+++ b/src/device.c
@@ -7896,7 +7896,7 @@ bool btd_device_set_gatt_db(struct btd_device *device, struct gatt_db *db)
return false;
clone = gatt_db_clone(db);
- if (clone)
+ if (!clone)
return false;
gatt_db_unregister(device->db, device->db_id);
--
2.25.1
^ permalink raw reply related
* RE: [BlueZ] device: fix inverted NULL check in gatt_db clone
From: bluez.test.bot @ 2026-05-18 6:36 UTC (permalink / raw)
To: linux-bluetooth, winter91
In-Reply-To: <tencent_9B9A0B74FBCC9D4EF1CA4D8EE89DFB444606@qq.com>
[-- Attachment #1: Type: text/plain, Size: 1830 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=1096236
---Test result---
Test Summary:
CheckPatch FAIL 0.40 seconds
GitLint PASS 0.27 seconds
BuildEll PASS 17.72 seconds
BluezMake PASS 605.54 seconds
CheckSmatch PASS 311.42 seconds
bluezmakeextell PASS 167.26 seconds
IncrementalBuild PASS 592.92 seconds
ScanBuild PASS 915.40 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ] device: fix inverted NULL check in gatt_db clone
WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12 chars of sha1> ("<title line>")' - ie: 'Fixes: cbe4144dea6f ("set: Attempt to use existing set gatt-db")'
#87:
Fixes: cbe4144 ("set: Attempt to use existing set gatt-db")
/github/workspace/src/patch/14577840.patch total: 0 errors, 1 warnings, 8 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14577840.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
https://github.com/bluez/bluez/pull/2132
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: btmtk: fix urb->setup_packet leak in error paths
From: bluez.test.bot @ 2026-05-18 6:17 UTC (permalink / raw)
To: linux-bluetooth, liujiajia
In-Reply-To: <20260518022402.20398-1-liujiajia@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 882 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=1096249
---Test result---
Test Summary:
CheckPatch PASS 0.68 seconds
GitLint PASS 0.30 seconds
SubjectPrefix PASS 0.11 seconds
BuildKernel PASS 27.15 seconds
CheckAllWarning PASS 29.85 seconds
CheckSparse PASS 28.26 seconds
BuildKernel32 PASS 26.02 seconds
TestRunnerSetup PASS 574.83 seconds
IncrementalBuild PASS 25.59 seconds
https://github.com/bluez/bluetooth-next/pull/208
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v9] Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
From: bluez.test.bot @ 2026-05-18 6:16 UTC (permalink / raw)
To: linux-bluetooth, w15303746062
In-Reply-To: <20260518024949.439299-1-w15303746062@163.com>
[-- Attachment #1: Type: text/plain, Size: 4142 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=1096260
---Test result---
Test Summary:
CheckPatch PASS 0.75 seconds
GitLint FAIL 0.33 seconds
SubjectPrefix PASS 0.12 seconds
BuildKernel PASS 25.77 seconds
CheckAllWarning PASS 28.71 seconds
CheckSparse PASS 27.21 seconds
BuildKernel32 PASS 25.26 seconds
TestRunnerSetup PASS 532.29 seconds
IncrementalBuild PASS 25.10 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v9] Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
54: B1 Line exceeds max length (398>80): "- Addressed a critical flaw identified in v8 where premature cancellation of write_work allowed active protocol timers to immediately reschedule it. The teardown sequence in hci_uart_tty_close() now strictly clears HCI_UART_PROTO_READY *before* calling cancel_work_sync(&hu->write_work). This permanently locks out hci_uart_tx_wakeup(), completely resolving the lingering UAF and double-free races."
55: B1 Line exceeds max length (170>80): "- Documented that skipping hu->proto->flush() via early flag clearance is intrinsically safe, as hu->proto->close() executes subsequently to purge all unacked/rel queues."
58: B1 Line exceeds max length (122>80): "- Corrected the teardown sequence in hci_uart_tty_close() by unconditionally canceling write_work BEFORE hci_uart_close()."
59: B1 Line exceeds max length (182>80): "- Moved hu->hdev->stat.byte_rx increment inside the proto_lock read-side critical section in hci_uart_tty_receive() to prevent read-side UAF against concurrent registration failures."
60: B1 Line exceeds max length (190>80): "- Added cancel_work_sync(&hu->write_work) inside hci_uart_close() to eliminate the race condition between write_work and hci_uart_flush() when the interface is brought down via the HCI core."
63: B1 Line exceeds max length (133>80): "- Reverted disable_work_sync() back to cancel_work_sync() across all error and close paths to preserve user-space retry capabilities."
64: B1 Line exceeds max length (142>80): "- Synchronized workqueue teardown safely by atomically clearing PROTO_READY / PROTO_INIT under proto_lock prior to calling cancel_work_sync()."
65: B1 Line exceeds max length (142>80): "- Fixed a Use-After-Free (UAF) vulnerability in the teardown sequence by relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev)."
66: B1 Line exceeds max length (151>80): "- Added cancel_work_sync(&hu->init_ready) at the very beginning of hci_uart_tty_close() to serialize teardown against active asynchronous registration."
69: B1 Line exceeds max length (130>80): "- Fixed missing `hu->proto_lock` write lock in hci_uart_init_work() error path to prevent race with readers (reported by Sashiko)."
70: B1 Line exceeds max length (143>80): "- Added disable_work_sync() instead of cancel_work_sync() for `hu->write_work` in hci_uart_init_work() and hci_uart_register_dev() error paths."
73: B2 Line has trailing whitespace: "- Relocated disable_work_sync() to the very top of hci_uart_tty_close(), "
74: B1 Line exceeds max length (85>80): " before hci_uart_close(), to ensure no new work is submitted during device teardown."
77: B2 Line has trailing whitespace: "- Adopted Luiz's suggestion to use disable_work_sync() instead of "
https://github.com/bluez/bluetooth-next/pull/209
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 83e927: device: fix inverted NULL check in gatt_db clone
From: github-actions[bot] @ 2026-05-18 5:52 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1096236
Home: https://github.com/bluez/bluez
Commit: 83e92707b9831b25a4de0b66f5b6cea4509c63c2
https://github.com/bluez/bluez/commit/83e92707b9831b25a4de0b66f5b6cea4509c63c2
Author: Zhao Dongdong <zhaodongdong@kylinos.cn>
Date: 2026-05-18 (Mon, 18 May 2026)
Changed paths:
M src/device.c
Log Message:
-----------
device: fix inverted NULL check in gatt_db clone
gatt_db_clone() returns NULL on failure so the condition was inverted.
With the old check a successful clone (non-NULL) would return false and
skip swapping the device's GATT database, while a failure (NULL) would
fall through and dereference a NULL pointer a few lines below.
Fix by negating the condition: only bail out early if the clone failed;
proceed with the swap when the clone actually succeeds.
Fixes: cbe4144 ("set: Attempt to use existing set gatt-db")
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
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