CVE-2026-31660

What it actually does

This is a Linux kernel availability flaw in the NFC PN533/PN532 serial receive path. The vulnerable receive callback can consume incoming bytes, deliver a complete NFC frame, then fail to allocate a new socket buffer for subsequent input. When allocation fails, the driver incorrectly reports that no bytes were accepted even though bytes were already consumed and can leave the receive buffer pointer unset. A later receive callback may then dereference a NULL buffer during byte append handling, causing a kernel crash or panic. The impact is denial of service, not data theft or privilege escalation, and exploitation requires local access or a local ability to interact with the affected NFC/serial device path.

Why it matters to the business

Systems using the affected Linux kernel NFC PN533/PN532 driver may be locally crashed, disrupting workloads, kiosks, embedded devices, payment or badge-reader systems, test benches, or endpoints that rely on NFC hardware. The CVSS score indicates moderate severity with high availability impact, while the very low EPSS score, flat EPSS trend, lack of known exploitation, and absence from the CISA KEV catalog suggest limited current threat activity. Risk is highest for systems where untrusted local users, containers with device access, or exposed physical NFC/serial interfaces can interact with PN533-compatible hardware.

How an attack unfolds

An attacker first needs local access to a system where the vulnerable Linux kernel has the PN533/PN532 NFC serial driver enabled and reachable. The attacker then interacts with the NFC device or its serial receive path and supplies input that causes the driver to consume bytes and complete a frame. If the kernel cannot allocate the next receive socket buffer at the right point, the vulnerable code path reports incorrect byte accounting and leaves the receive buffer unset. On the next receive callback, the driver may attempt to append data to the missing buffer, triggering a NULL pointer dereference in kernel context. The practical result is usually a kernel oops, panic, or device crash requiring service restart or reboot. There is no public indication of mature exploit code, ransomware use, or named threat actor exploitation for this issue.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the PN533 receive-buffer allocation logic. Because no exact fixed version was provided, use the kernel packages supplied by the relevant Linux distribution, appliance vendor, or long-term kernel branch that explicitly references the fix for the NFC PN533 change: "nfc: pn533: allocate rx skb before consuming bytes." If NFC support is not required, reduce exposure by disabling or blacklisting PN533-related NFC modules, removing access to PN533/PN532 serial devices, and preventing untrusted users or containers from accessing NFC/serial device nodes. Where patching must be delayed, limit local shell access, restrict membership in groups that can access serial/NFC devices, and apply device cgroup or udev policy controls to block unnecessary hardware access.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix or a backported patch for the PN533 receive-buffer allocation issue. Validate exposure by checking whether PN533/PN532 NFC support is present, built into the kernel, or loaded as modules such as pn533, pn533_uart, pn533_usb, or nfc. Review distribution changelogs, kernel source, or package advisories for the fix text "nfc: pn533: allocate rx skb before consuming bytes." After remediation, reboot into the patched kernel and verify the active kernel version with standard system inventory tooling. For mitigation validation, confirm unused NFC modules are not loaded, cannot be auto-loaded, and that untrusted users or workloads cannot access relevant NFC or serial device nodes.

Typical attack path

1. Identify a Linux system running an affected kernel with the PN533/PN532 NFC serial driver enabled or loaded.
2. Obtain local privileges sufficient to interact with the NFC hardware, serial device, or exposed device node.
3. Send or induce NFC/serial traffic that reaches the pn532_receive_buf receive callback.
4. Cause the receive path to complete a frame and then encounter receive-buffer allocation failure or pressure-dependent allocation behavior.
5. Trigger a subsequent receive callback while the driver's receive buffer pointer is NULL.
6. Cause a kernel NULL pointer dereference, leading to an oops, panic, or system availability loss.

How to detect it

Look for evidence of kernel crashes or NFC driver faults rather than network indicators. Useful sources include kernel ring buffer logs, system journal entries, /var/log/kern.log, /var/log/messages, crash dump repositories, kdump/vmcore records, endpoint telemetry for kernel panics, and audit logs showing local access to NFC or serial device nodes shortly before a crash. Search for NULL pointer dereferences, kernel oops or panic events, and stack traces referencing pn533, pn532_receive_buf, pn533_recv_frame, skb_put_u8, NFC, serdev, or related PN533 modules. Correlate these events with local user sessions, container device mappings, udev activity, module load events, and interactions with /dev/tty* or NFC-related device files. There are no known public threat actors or ransomware campaigns associated with this issue, so detection should focus on crash forensics, suspicious local device access, and repeated attempts to induce kernel faults.

• pn532_receive_buf
• pn533_recv_frame
• skb_put_u8
• pn533
• pn533_uart
• pn533_usb
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• Unable to handle kernel NULL pointer dereference
• nfc: pn533
• serdev
• drivers/nfc/pn533

What your security team should do

• Prioritize patching systems that have NFC PN533/PN532 hardware, embedded NFC readers, kiosk functions, physical-access integrations, or untrusted local users.
• Inventory Linux systems for loaded or available PN533/NFC kernel modules and for exposed NFC or serial device nodes.
• If NFC is not operationally required, disable or blacklist PN533-related modules and restrict device-node access as an immediate mitigation.
• Monitor kernel logs for NULL pointer dereferences, kernel oops messages, panics, and pn533 or pn532 receive-path errors.
• Treat crashes on systems with NFC hardware as potentially security-relevant until kernel logs and hardware access history are reviewed.
• Track vendor kernel advisories rather than relying only on upstream version numbers, because Linux distributions often backport security fixes without changing to the newest upstream kernel.
• Given the low EPSS, no KEV listing, no ransomware association, and no known exploit maturity, handle as routine-to-expedited availability hardening unless the affected systems are safety-critical, public-facing kiosks, or shared multi-user hosts.