In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: reject short frames before parsing
A BNEP peer can send a short BNEP SDU. bneprxframe() 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. bneprxcontrol() also dereferences the control opcode without rejecting an empty control payload.
Use skbpulldata() for the fixed fields in bneprxframe() 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 BNEPSETUPCONNREQ, name the UUID-size byte before pulling the setup payload. struct bnepsetupconnreq 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 bneprxframe.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: dumpstacklvl+0xb3/0x140 (?:?) printaddressdescription+0x57/0x3a0 (?:?) bneprxframe+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virtaddrvalid+0x1ba/0x3a0 (?:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) kasanaddrtoslab+0x21/0x60 (?:?) kasanreport+0xe0/0x110 (?:?) processonework+0xfce/0x17e0 (kernel/workqueue.c:3200) workerthread+0x65c/0xe40 (?:?) __kthreadparkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) rawspinunlock_irq+0x28/0x50 (?:?) retfromfork+0x586/0x870 (?:?) __switchto+0x74f/0xdc0 (?:?) retfromforkasm+0x1a/0x30 (?:?)
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53253.json",
"cna_assigner": "Linux"
}