CVE-2026-63915

What it actually does

This Linux kernel NFC HCI parsing flaw allows a nearby malicious NFC peer to send a zero-length HCP frame that reaches NFC HCI receive paths before the kernel verifies that the socket buffer contains the expected header byte. This can cause an out-of-bounds heap read when packet header data is accessed. In a non-final fragment path, the same malformed frame can cause message length underflow to UINT_MAX and trigger skb_over_panic() during reassembly, leading to kernel memory safety failure and likely system crash. The CVSS vector indicates adjacent-network exploitation with no authentication or user interaction required, and potential high confidentiality, integrity, and availability impact, although practical exploitation details are not publicly mature based on the provided exploit maturity.

Why it matters to the business

Systems with enabled NFC hardware and vulnerable Linux kernels may be disrupted or potentially exposed to kernel-level memory corruption by an attacker in close physical proximity using a malicious NFC device or tag emulator. The most likely operational consequence is device crash, reboot, or denial of service; depending on exploit development, kernel memory disclosure or deeper compromise may also be possible. This is most relevant for laptops, mobile/embedded Linux devices, kiosks, payment-adjacent terminals, industrial handhelds, and other Linux systems where NFC is present and enabled. EPSS is currently low and the issue is not listed in KEV, but the high CVSS score and no-auth adjacent attack path warrant timely remediation for NFC-capable fleets.

How an attack unfolds

An attacker positions a malicious NFC peer close enough to communicate with a vulnerable Linux system that has NFC enabled. The attacker sends a malformed zero-byte HCP frame through the NFC SHDLC/HCI path. Vulnerable kernel functions process the received socket buffer and access packet->header before confirming that the buffer contains at least one byte. This produces an out-of-bounds heap read. If the malformed zero-byte frame is treated as a non-final fragment, the reassembly logic can underflow the message length to UINT_MAX, and a later write to the reassembled socket buffer can trigger skb_over_panic(), commonly resulting in a kernel panic or system crash. A more advanced exploit would attempt to use the memory safety primitive for information disclosure or control-flow manipulation, but no public exploit maturity is indicated in the supplied data.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the NFC HCI fix adding pskb_may_pull() validation before packet->header is accessed in nfc_hci_recv_from_llc() and nci_hci_data_received_cb(). Because exact fixed package versions were not provided, use the relevant Linux distribution, device vendor, or kernel stable branch advisories to identify the patched kernel release. Where immediate patching is not possible, reduce exposure by disabling NFC in firmware/BIOS/UEFI, removing or blacklisting NFC kernel modules where operationally acceptable, disabling NFC services, and restricting physical proximity to NFC-capable systems. For embedded products, rebuild and deploy firmware with the patched kernel and validate that NFC functionality still behaves correctly after the update.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems with NFC hardware, NFC services enabled, or loaded NFC-related kernel modules. Verify the running kernel package includes the upstream or vendor backport for the NFC HCI header length validation fix. Check kernel changelogs or source for added pskb_may_pull() checks before first access to packet->header in nfc_hci_recv_from_llc() and nci_hci_data_received_cb(). Validate mitigation by confirming NFC is disabled where required, NFC modules are not loaded where disabled, and systems no longer accept NFC traffic if NFC has been administratively turned off. For patched systems, perform controlled NFC regression testing and review kernel logs to ensure malformed NFC frames do not produce kernel warnings, panics, skb_over_panic(), or crashes.

Typical attack path

1. Identify or target a Linux device with NFC hardware enabled and running a vulnerable kernel build.
2. Move within NFC communication range of the target device using a malicious NFC peer, tag emulator, or NFC-capable attack device.
3. Initiate NFC communication that reaches the Linux NFC SHDLC/HCI receive path.
4. Send a crafted zero-byte HCP frame that bypasses earlier assumptions and reaches NFC HCI parsing functions.
5. Trigger an out-of-bounds heap read when the kernel accesses the HCP packet header without first validating buffer length.
6. Optionally send the zero-byte frame as a non-final fragment to trigger reassembly length underflow and skb_over_panic().
7. Cause kernel instability, panic, reboot, or potentially attempt further kernel memory exploitation if reliable primitives are developed.

How to detect it

Detection is primarily based on kernel logs, crash dumps, system reboot telemetry, and NFC service activity because the attack occurs in kernel NFC packet parsing and may not generate application-level logs. Review journald, syslog, dmesg, kernel ring buffer captures, kdump/vmcore artifacts, endpoint crash reports, and device management telemetry for unexplained kernel panics or reboots correlated with NFC activity or physical proximity events. Look for references to NFC HCI receive functions, SHDLC, sk_buff allocation/write failures, skb_over_panic(), kernel BUG/Oops messages, or call traces involving nfc_hci_recv_from_llc(), nci_hci_data_received_cb(), and NFC drivers. If crash dumps are available, inspect stack traces for NFC HCI parsing and malformed or zero-length skb data around the time of failure. Also review whether NFC was enabled shortly before the incident, whether NFC modules were loaded, and whether the affected system was in a location where close-range NFC interaction was possible. Absence of logs does not rule out exploitation, especially if the system crashed before buffers were persisted.

• skb_over_panic
• kernel BUG at net/core/skbuff.c
• kernel panic
• Oops:
• Call Trace:
• nfc_hci_recv_from_llc
• nci_hci_data_received_cb
• nfc_hci
• shdlc
• HCP
• sk_buff
• skb_over_panic: text
• dmesg | grep -i nfc
• journalctl -k | grep -i nfc
• journalctl -k | grep -i skb_over_panic
• journalctl -k | grep -i "nfc_hci_recv_from_llc"
• journalctl -k | grep -i "nci_hci_data_received_cb"

What your security team should do

• Prioritize patching NFC-capable Linux endpoints, embedded devices, kiosks, and mobile/field systems, especially those used in public or physically accessible locations.
• Inventory systems for enabled NFC hardware and loaded NFC kernel modules; treat NFC-enabled devices as the primary exposure population.
• Apply vendor kernel updates that include the NFC HCI pskb_may_pull() validation fix; if no vendor package is available, track the appropriate kernel stable backport.
• Disable NFC on systems that do not require it, using firmware settings, operating system configuration, service disablement, or module blacklisting as appropriate.
• Increase physical security controls around NFC-capable systems until patched, because exploitation requires close-range adjacent access.
• Monitor kernel logs and crash telemetry for NFC, HCI, SHDLC, sk_buff, skb_over_panic(), kernel BUG, or panic messages.
• Create SIEM searches for the provided kernel panic and NFC-related indicators, recognizing that successful exploitation may leave only crash artifacts.
• For embedded or appliance products, coordinate firmware updates and include malformed NFC frame testing in acceptance validation.
• Track threat intelligence for any change in exploit maturity, KEV status, or named actor exploitation; current supplied data indicates no KEV listing and no mature public exploit.