Katalog CVE

CVE-2026-53253

WysokieCVSS 7.1
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.27%

Percentyl 19 - wyżej niż 19% wszystkich znanych CVE

Streszczenie

W jądrze Linux wykryto podatność w podsystemie Bluetooth BNEP, polegającą na braku walidacji długości ramek przed ich parsowaniem. Zdalny atakujący może wysłać krótką ramkę BNEP SDU, co prowadzi do odczytu poza zakresem bufora (slab-out-of-bounds) i potencjalnie do naruszenia stabilności systemu.

Ocena ryzyka

Ryzyko obejmuje możliwość zdalnego wywołania błędu KASAN (odczyt poza zakresem) w jądrze, co może prowadzić do awarii systemu (kernel panic) lub potencjalnej eskalacji uprawnień. Podatność jest szczególnie niebezpieczna w środowiskach z włączoną obsługą Bluetooth.

Rekomendacja

Zaleca się natychmiastową aktualizację jądra Linux do wersji zawierającej poprawkę (commit z opisem CVE-2026-53253). Jeśli aktualizacja nie jest możliwa, należy rozważyć wyłączenie modułu Bluetooth BNEP (bnep) lub ograniczenie zaufanych połączeń Bluetooth.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

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. 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 (?:?)

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS