CVE-2026-80802
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A hardware-connected NFC chip can send bad data that crashes or takes over the computer running the affected Linux software.
- Exploitation
- Physical Access
- Attacker needs
- Physical Access
- Complexity
- High
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Unvalidated u16 length from device in fdp_nci_i2c_read allows out-of-bounds stack write past a 261-byte buffer or short-frame processing that skips header/LRC handling; additionally, repeated skb allocation without freeing prior buffers on malformed packet sequences causes memory leaks.
Why it matters to the business
Local or physically proximate attackers with a malicious or compromised NFC controller can crash the kernel or achieve code execution on affected Linux systems, leading to denial of service or full host compromise; the flaw affects any device exposing the FDP NCI I2C interface.
How an attack unfolds
An attacker supplies a counterfeit or interposed I2C device that returns an out-of-range length byte pair; the kernel copies beyond the on-stack buffer, overwriting the stack canary and return address, or triggers repeated skb allocations that leak memory until the system becomes unstable.
How to fix it
Apply the upstream kernel patch that enforces length bounds between FDP_NCI_I2C_MIN_PAYLOAD and FDP_NCI_I2C_MAX_PAYLOAD and frees the prior skb before the next allocation; rebuild and reboot with the fixed kernel image.
How to confirm the fix worked
Confirm the patched fdp.c contains the explicit range check and skb release before the next i2c_master_recv call; exercise the read path with both valid and out-of-range length responses and verify no oops or memory leak counters increase.
Typical attack path
- Gain physical or bus-level access to the I2C lines connected to an FDP NFC controller
- Emulate or tamper with the controller to return a malicious length field outside the expected payload range
- Trigger the fdp_nci_i2c_read path via normal NFC operations or crafted traffic
- Overwrite stack control data to hijack execution or exhaust memory through skb leaks
How to detect it
Inspect kernel logs for stack canary violations or skb allocation warnings originating from nfc/fdp; correlate with NFC device attach events and monitor for repeated allocation failures without corresponding frees.
What your security team should do
- Prioritize kernel update on all systems exposing NFC FDP hardware within the next maintenance window
- Disable the nfc/fdp module if NFC functionality is not required
- Monitor vendor advisories for distribution backports of the skb and length fixes
The record
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|