CVE-2026-43032

What it actually does

This is a Linux kernel availability flaw in the NFC PN533/PN532 UART driver. The receive path appends incoming UART bytes to an skb while waiting for a valid PN532 frame. If a local attacker can feed a continuous malformed byte stream that never forms a valid frame header, the receive buffer can grow until the kernel hits the skb tail limit, potentially triggering a kernel warning, panic, or crash. The impact is denial of service; the description does not indicate confidentiality loss, privilege escalation, or data modification.

Why it matters to the business

Systems using the affected Linux kernel with PN533/PN532 NFC UART hardware or the vulnerable driver enabled may be susceptible to local denial of service, causing device crashes, service interruption, or operational downtime. The risk is narrower than remotely exploitable flaws because exploitation requires local capability to influence the UART/NFC receive path, and the current EPSS is very low with no known KEV listing or public exploit maturity reported.

How an attack unfolds

An attacker first needs local access or an execution context that can send malformed data into the PN533/PN532 UART receive path, such as access to a serial-connected NFC device or a component that can influence that UART stream. Instead of sending a valid PN532 frame, the attacker sends a continuous stream of bytes that does not contain a recognizable frame header. The vulnerable pn532_receive_buf() logic keeps appending bytes to dev->recv_skb while waiting for pn532_uart_rx_is_frame() to identify a complete frame. Because the partial frame is not dropped when the fixed receive buffer is full, the skb can be extended until skb_put_u8() reaches the tail limit. This can lead to a kernel crash or panic, taking the host or embedded device offline. No known ransomware use, KEV status, or named threat actor exploitation has been reported in the supplied data.

How to fix it

Update to a Linux kernel build from the distribution or device vendor that includes the PN533 UART receive-buffer bound fix. No exact fixed package versions were provided in the input, so prioritize vendor advisories for the affected kernel branch and confirm the patch for the NFC pn533 UART driver is included. Where immediate patching is not possible, mitigate by disabling unused NFC support, unloading or blacklisting the affected PN533/PN532 UART driver modules where operationally safe, restricting local access to serial/UART devices, and physically or logically isolating untrusted NFC/UART inputs. Embedded and appliance vendors should rebuild kernels with the corrected driver and validate that malformed UART input is dropped once the fixed receive buffer is full.

How to confirm the fix worked

Confirm the running kernel version maps to a vendor release containing the fix, not only that packages are installed on disk. Verify whether PN533/PN532 NFC UART support is present or loaded using kernel module inventory and device configuration checks. If NFC UART functionality is not required, validate that the relevant driver is not loaded after reboot and cannot be automatically loaded by normal users. For patched systems, test in a controlled lab by sending malformed UART/NFC input and confirming the driver drops the partial frame at the fixed buffer length without kernel warnings, panics, or skb tail-limit failures. Review kernel logs after testing and after production rollout for absence of skb overrun or pn533/pn532 receive-path errors.

Typical attack path

1. Identify a Linux system or embedded device with the PN533/PN532 NFC UART driver in use or loadable.
2. Obtain local access or another local mechanism to inject bytes into the relevant UART/NFC receive path.
3. Send a long malformed byte stream that does not contain a valid PN532 frame header.
4. Cause the driver to keep appending bytes to the receive skb while waiting for a complete frame.
5. Exhaust the receive buffer boundary and trigger an skb tail-limit failure, kernel warning, panic, or crash.
6. Repeat the malformed traffic to maintain denial of service until the vulnerable driver is patched, disabled, or the input path is blocked.

How to detect it

To determine whether this was already exploited, review kernel and system logs for crashes, panics, or skb boundary errors associated with NFC, PN533, PN532, UART, or serial activity. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/messages, persistent crash logs, kdump/vmcore records, pstore/ramoops on embedded devices, and EDR telemetry that captures kernel panic or reboot causes. Look for repeated unexpected reboots preceded by pn533/pn532 driver messages, skb_put or skb_over_panic errors, serial/UART receive anomalies, or malformed NFC activity. Correlate timestamps with local user sessions, services that access serial devices, udev events, NFC daemon activity, and physical access events where available. Because the flaw is a malformed-input denial-of-service condition, there may be no durable file artifact beyond logs and crash dumps; absence of logs is not proof of no exploitation if the system does not persist kernel logs across reboots.

• pn533
• pn532
• pn533_uart
• pn532_receive_buf
• pn532_uart_rx_is_frame
• skb_put_u8
• skb_over_panic
• skbuff: skb_over_panic
• kernel panic
• BUG: unable to handle kernel
• Oops:
• NFC: pn533
• PN532_UART_SKB_BUFF_LEN
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore
• /var/crash

What your security team should do

• Inventory Linux systems and embedded devices that use NFC hardware, PN533/PN532 controllers, or NFC UART drivers.
• Prioritize patching devices where local users, peripheral devices, kiosks, labs, manufacturing systems, or exposed physical interfaces can influence UART/NFC traffic.
• Apply the vendor kernel update containing the PN533 UART receive-buffer bound fix; if unavailable, request a backport from the OS or device vendor.
• Disable, unload, or blacklist PN533/PN532 NFC UART support on systems that do not require it.
• Restrict permissions to serial/UART device nodes and limit local users or services that can interact with NFC/UART hardware.
• Monitor kernel logs for skb tail-limit failures, kernel panics, and pn533/pn532 receive-path anomalies, especially on devices with NFC peripherals.
• For embedded fleets, include malformed UART/NFC frame testing in release validation before deploying updated firmware.
• Treat exploitation likelihood as currently low because EPSS is 0.00123, stable over 30 days, not in CISA KEV, and no exploit maturity was reported, but still remediate where affected hardware is present because the failure mode can be a full system outage.