Look up another CVE · open CVE-2026-53253 in the interactive tracker
CVE-2026-53253
Bluetooth: bnep: reject short frames before parsing
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem net/bluetooth. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-53253 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 | fixedDLA-4665-1 · 2026-07-03 · text | 6.1.176-1 | Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)
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.
net/bluetooth/bnep/core.c
- What this is
- BLUETOOTH SUBSYSTEMMAINTAINERS section matched on net/bluetooth/ · linux-bluetooth@vger.kernel.org · Supported
- Kernel module
- bnep
Check it on the machine
grep -wE 'CONFIG_BT|CONFIG_BT_BNEP' /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 bnepPrints 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 switches
- CONFIG_BT, CONFIG_BT_BNEP
- Reads as
- all on means the file is compiled; any one off means it is not.
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
- 2026-06-25 (4 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.27%, higher than 17.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/bluetooth
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.12 | 5.15.210 | 0ef2ea86c82b |
| 2.6.12 | 6.1.176 | 2b83afb19293 |
| 2.6.12 | 6.6.143 | 691f14b6a48b |
| 2.6.12 | 6.12.94 | d76dec1a3712 |
| 2.6.12 | 6.18.36 | c893e17d2809 |
| 2.6.12 | 7.0.13 | be837cd09897 |
| 2.6.12 | 7.1 | 6770d3a8acdf |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4671-1 | 2026-07-05 | bullseye 6.1.176-1~deb11u1 | tracker |
| DLA-4665-1 | 2026-07-03 | bookworm 6.1.176-1 | tracker |
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
- Bluetooth BNEP traffic is delivered by an adjacent Bluetooth/L2CAP peer over the PAN channel. The vulnerable parser is reached from received Bluetooth packets, not from an Internet-routable network path.
- AC:LAttack complexity, low
- A peer can trigger the bug with a deliberately short BNEP SDU such as a one-byte control frame or truncated setup request. No race, heap grooming, or victim state beyond an established BNEP channel is required to reach the invalid read.
- PR:NPrivileges required, none
- The attacker is the remote Bluetooth BNEP peer sending payload bytes after the channel exists and needs no privileges on the target system. The local CAP_NET_ADMIN check only applies to the trusted userspace component that creates the BNEP session.
- UI:NUser interaction, none
- Once a BNEP/PAN service or connection is active, the malicious peer can send the malformed SDU without further victim action. No file opening, mount, or interactive operation is needed for the vulnerable receive path.
- S:UScope, unchanged
- The impact is within the target kernel/Bluetooth networking stack security authority. There is no VM, IOMMU, or separate sandbox boundary crossed.
- C:LConfidentiality impact, low
- The bug is a fixed-field out-of-bounds read of one-byte BNEP type/opcode/UUID-size fields, with at most limited adjacent heap-byte exposure. It is not an arbitrary kernel memory read primitive.
- I:NIntegrity impact, none
- The vulnerable paths perform out-of-bounds reads before validation but do not write past bounds or corrupt attacker-chosen kernel structures. No credible integrity impact follows from the parsed short-frame bug itself.
- A:HAvailability impact, high
- The fix commit reproduces a KASAN slab-out-of-bounds report in bnep_rx_frame from attacker-controlled short frames. Repeated adjacent peer-triggered malformed frames can crash or panic affected/hardened kernels, causing denial of service.