CVE-2026-63991

What it actually does

This is a Linux kernel denial-of-service flaw in the Bluetooth 6LoWPAN multicast transmit path. The kernel function send_mcast_pkt() calls skb_clone() but does not verify whether the allocation succeeded. Under memory pressure, skb_clone() can return NULL; the unpatched code then passes that NULL pointer to send_pkt(), which dereferences skb->data and can trigger a kernel NULL pointer dereference. Depending on kernel panic/oops configuration, this can crash the kernel, reset the system, or destabilize Bluetooth/6LoWPAN networking.

Why it matters to the business

Systems that use Bluetooth 6LoWPAN can be forced into instability or outage if an attacker can trigger the vulnerable path under memory pressure. The most likely consequence is service interruption rather than data theft. Exposure is narrower than typical network-facing Linux kernel issues because Bluetooth 6LoWPAN must be enabled and reachable, exploit maturity is currently reported as none, EPSS is very low, and the issue is not in CISA KEV or known ransomware use.

How an attack unfolds

An attacker first needs access to a system where Bluetooth 6LoWPAN support is enabled and participating in Bluetooth-based IPv6/low-power networking. From radio proximity, a paired/connected device, or a compromised adjacent Bluetooth 6LoWPAN peer, the attacker induces multicast packet handling through the vulnerable send_mcast_pkt() path. To make exploitation reliable, the attacker or another workload must create memory pressure so that skb_clone() fails. On an unpatched kernel, the failed allocation returns NULL, but the return value is not checked. The kernel then calls send_pkt() with a NULL socket buffer and dereferences skb->data, causing a NULL pointer dereference. The end result is typically a kernel oops, kernel panic, reboot, or loss of Bluetooth/6LoWPAN network service.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the Bluetooth 6LoWPAN fix adding a NULL check after skb_clone() in send_mcast_pkt(). If no fixed package version is available from the distribution yet, track the relevant stable kernel advisory and prioritize kernels containing the upstream fix titled "Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()". As interim mitigation, disable Bluetooth 6LoWPAN where it is not required, disable Bluetooth on systems that do not need it, unload or blacklist related modules where operationally safe, restrict Bluetooth pairing and radio exposure, and monitor systems for memory pressure that could make allocation-failure bugs easier to trigger.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor build that includes the Bluetooth 6LoWPAN skb_clone() NULL-check fix. Validate both the installed kernel package and the active kernel returned by uname -r after reboot. Where source or vendor patch metadata is available, verify that send_mcast_pkt() checks the skb_clone() return value before calling send_pkt(). Confirm whether Bluetooth 6LoWPAN is enabled by reviewing kernel configuration, loaded modules, and active Bluetooth/6LoWPAN interfaces. For mitigation validation, verify Bluetooth/6LoWPAN modules are not loaded or the Bluetooth service/radio is disabled on systems where the feature is unnecessary.

Typical attack path

1. Identify a Linux system with Bluetooth and Bluetooth 6LoWPAN enabled.
2. Gain adjacent Bluetooth/6LoWPAN reachability, such as through radio proximity, a connected peer, or a compromised device on the same Bluetooth 6LoWPAN segment.
3. Generate or induce multicast 6LoWPAN traffic that causes send_mcast_pkt() to clone packets for peers.
4. Increase memory pressure or rely on existing memory exhaustion conditions so skb_clone() returns NULL.
5. Trigger the vulnerable code path so send_pkt() dereferences the NULL skb pointer.
6. Cause a kernel oops, panic, reboot, or Bluetooth/6LoWPAN service disruption.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, system journals, crash dumps, and Bluetooth service logs. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, kdump/vmcore records, systemd-coredump metadata, Bluetooth daemon logs, and EDR telemetry for kernel panic or reboot events. Focus on kernel oops or panic entries showing NULL pointer dereference with stack frames that include Bluetooth 6LoWPAN functions, send_mcast_pkt(), send_pkt(), skb_clone(), or skb/data dereference failures. Correlate crash times with Bluetooth connections, 6LoWPAN multicast activity, unexpected memory pressure, low-memory killer events, or unexplained reboots. Because this is a denial-of-service condition, there may be no persistent attacker artifact beyond crash telemetry and Bluetooth/radio activity around the time of failure.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• send_mcast_pkt
• send_pkt
• skb_clone
• skb->data
• Bluetooth: 6lowpan
• bluetooth 6lowpan
• bt_6lowpan
• bluetooth_6lowpan
• 6lowpan
• Call Trace:
• Out of memory
• oom-killer

What your security team should do

• Inventory Linux systems with Bluetooth hardware, Bluetooth services, or Bluetooth 6LoWPAN enabled; prioritize systems in exposed, physically accessible, embedded, IoT, industrial, or edge locations.
• Patch affected Linux kernels through the operating system vendor and reboot into the fixed kernel.
• Disable Bluetooth and Bluetooth 6LoWPAN wherever they are not business-required.
• If patching is delayed, restrict Bluetooth pairing, reduce physical/radio exposure, and monitor for abnormal Bluetooth/6LoWPAN multicast activity and kernel memory pressure.
• Review kernel crash logs and historical telemetry for NULL pointer dereferences involving send_mcast_pkt(), send_pkt(), skb_clone(), Bluetooth, or 6LoWPAN.
• Because exploit maturity is currently none, EPSS is low, and the issue is not KEV-listed, handle through normal kernel patch SLAs unless Bluetooth 6LoWPAN is widely used or exposed in high-availability environments.