Look up another CVE · open CVE-2024-36968 in the interactive tracker
CVE-2024-36968
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
Published 2024-06-08 (2 years ago) by the Linux kernel CNA. Subsystem include/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-36968 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.8.11-1 | Update the kernel and reboot. Fixed in 6.8.11-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.8.11-1 | Update the kernel and reboot. Fixed in 6.8.11-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.8.11-1 | Update the kernel and reboot. Fixed in 6.8.11-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/net/bluetooth/hci.h
include/net/bluetooth/hci_core.h
net/bluetooth/hci_conn.c
net/bluetooth/hci_event.c
net/bluetooth/iso.c
net/bluetooth/l2cap_core.c
net/bluetooth/sco.c
- What this is
- BLUETOOTH SUBSYSTEMMAINTAINERS section matched on include/net/bluetooth/ · linux-bluetooth@vger.kernel.org · Supported
- Kernel module
- bluetooth
Check it on the machine
grep -w CONFIG_BT /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w bluetoothPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_BT
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2024-06-08 (2 years ago)source
- CVSS
- 7.6 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.29%, higher than 20.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.39 | 6.6.32 | ad3f7986c5a0 |
| 2.6.39 | 6.8.11 | dfece2b4e375 |
| 2.6.39 | 6.9.2 | d2b2f7d3936d |
| 2.6.39 | 6.9.4 | 4d3dbaa25225 |
| 2.6.39 | 6.10 | a5b862c6a221 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The crash executes in `hci_rx_work` on receipt of an L2CAP LE Credit Based Connection Request from a Bluetooth LE peer in radio range, and the malformed buffer-size value originates from the HCI controller/transport — both are adjacent-network (Bluetooth PAN) attack surfaces, not routable network or purely local ones.
- AC:LAttack complexity, low
- Nothing is probabilistic or beyond attacker control: an attacker owning the HCI transport (rogue USB/UART dongle or over-the-air-compromised controller firmware) sets `le_mtu` deterministically, and on a device whose controller reports an out-of-spec LE buffer size a single unauthenticated L2CAP packet triggers it on the first try.
- PR:NPrivileges required, none
- `l2cap_le_connect_req()` is handled on the LE signalling channel and `smp_sufficient_security()` returns true immediately for the default `BT_SECURITY_LOW`, so no pairing, bonding, encryption or any local account is required.
- UI:NUser interaction, none
- The divide error occurs entirely inside the kernel receive workqueue when the L2CAP connect request is processed; no victim action such as accepting a pairing prompt or opening a file is involved.
- S:UScope, unchanged
- The faulting code and its impact are both inside the kernel's own security authority — no VM, IOMMU, or sandbox boundary is crossed.
- C:LConfidentiality impact, low
- The unvalidated MTU underflows size computations in `l2cap_create_basic_pdu()` (`conn->mtu - L2CAP_HDR_SIZE`) and `l2cap_segment_sdu()` (size_t `pdu_len`) and inflates `chan->mps` past the real link MTU, giving bounded length confusion in L2CAP PDU construction plus register/state exposure in the oops, rather than an arbitrary read primitive.
- I:LIntegrity impact, low
- The same u16/size_t underflows let malformed, oversized L2CAP PDUs and credit values be built and transmitted with sizes partly steered by the peer's `remote_mps`, corrupting protocol state in a limited way short of an arbitrary kernel write.
- A:HAvailability impact, high
- The `mps == 0` case is a hard divide error oops in the `hci_rx_work` kernel workqueue (fatal panic with panic_on_oops, dead Bluetooth stack otherwise), and the related `iso_mtu == 0` path spins forever in `iso_sock_sendmsg()` allocating skbs — an unrecoverable hang.