CVE-2026-80802: nfc: fdp: bound the device-reported read length and fix an skb leak
In the Linux kernel, the following vulnerability has been resolved:
nfc: fdp: bound the device-reported read length and fix an skb leak
fdpncii2cread() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2cmasterrecv() 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 [FDPNCII2CMINPAYLOAD, FDPNCII2CMAXPAYLOAD], 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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update/patch the nfc: fdp driver logic so fdp_nci_i2c_read() validates and bounds the device-supplied i2c_master_recv() count, and rejects lengths outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD] to prevent out-of-bounds access and the associated skb leak/overwrite.
nfc: fdp (kernel NFC FDP driver) bound device-reported read length = Reject/Bound i2c_master_recv() length to within [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD]
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's NFC FDP driver with an affected NFC controller or I2C path are exposed. The described attack sources include a malicious, counterfeit, or malfunctioning controller, or an I2C bus interposer.
What must an attacker control to exploit the memory-safety issue?
An attacker needs to cause the FDP controller communication path to report crafted packet-length bytes over I2C. Those lengths can exceed the fixed 261-byte stack buffer or be shorter than the minimum valid frame size.
What can happen if the issue is exploited?
An oversized device-reported length can cause a stack out-of-bounds write that may clobber the stack canary and return address. Invalid short lengths can also make subsequent header, LRC, and length handling read beyond a short receive.
Is there an additional impact beyond the out-of-bounds access?
Yes. If a device sends two data packets in one call, the receive loop can leak the first allocated data skb when the second allocation overwrites its reference.
What does the fix change?
The fix rejects payload lengths outside the FDP NCI I2C minimum and maximum bounds and forces resynchronization for corrupted packets. It also frees any previously allocated skb before allocating the next one.