CVE-2026-64403High· 7.1▾ TwilightIn the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and i…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 39.1 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 5.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.3%
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: validate option length before reading conf opt value
l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed.
An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers.
Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.
linux_kernel >= 3.16.66, < 3.17linux_kernel >= 3.18.138, < 3.19linux_kernel >= 4.4.178, < 4.5linux_kernel >= 4.9.167, < 4.10linux_kernel >= 4.14.110, < 4.15linux_kernel >= 4.19.33, < 4.20linux_kernel >= 5.0.6, < 5.10.261linux_kernel >= 5.11, < 5.15.212linux_kernel >= 5.16, < 6.1.178linux_kernel >= 6.2, < 6.6.145linux_kernel >= 6.7, < 6.12.96linux_kernel >= 6.13, < 6.18.39linux_kernel >= 6.19, < 7.1.4linux_kernel = 7.2Upgrade past the affected range:
linux_kernel 7.1.4Connected by shared product, vendor, weakness, or advisory.
CVE-2021-3739High· 7.1A NULL pointer dereference flaw was found in the btrfs_rm_device function in fs/btrfs/volumes.c in the Linux Kernel, where triggering the bug requires ‘CAP_SYS_ADMIN’
CVE-2026-64373Medium· 4.7In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path
CVE-2021-46983High· 7.5In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: Fix NULL deref when SEND is completed with error When running some traffic and taking down the link on peer, a retry counter exceeded error is received
CVE-2021-46948High· 7.5In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return…
CVE-2021-46933High· 7.8In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear. ffs_data_clear is indirectly called from both ffs_fs_kill_sb and ffs_ep0_release, so it ends up being called tw…
CVE-2021-46912High· 7.3In the Linux kernel, the following vulnerability has been resolved: net: Make tcp_allowed_congestion_control readonly in non-init netns Currently, tcp_allowed_congestion_control is global and writable; writing to it in any net namespac…