CVE-2026-90221: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: fix use of uninitialized memory in COREINITRSP parsing
ncicoreinitrsppacketv1() and ncicoreinitrsppacketv2() parse the COREINITRSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtualncidev) can declare a large numsupportedrfinterfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nciinitcompletereq(), triggering a KMSAN uninit-value warning.
Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rfinterface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rfinterfaces array and the trailing rsp2 structure.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Before parsing CORE_INIT_RSP, validate the skb contains enough bytes for the fixed-size header, verify at least 1 byte is available for the status field, and add skb length checks in the parsing loops (including checks that in v1 the skb is large enough for both variable-length fields; and in v2 bounds-check each variable-length rf_interface entry and its extension parameters, ensuring the skb can hold the trailing rsp_2 structure) before accessing packet fields.
Linux kernel NFC: nfc: nci (CORE_INIT_RSP parsing) skb length validation = Implement bounds checks for CORE_INIT_RSP parsing to prevent reading uninitialized slab memory
Event History
Frequently Asked Questions
What attacker capability is needed to trigger the issue?
The attacker needs to cause the NCI stack to process a malformed CORE_INIT_RSP packet. The data specifically identifies injection through virtual_ncidev as an example source of such a response.
What packet condition triggers the unsafe parsing?
A response can declare a large num_supported_rf_interfaces while containing too little data for the claimed interface information. Version 2 parsing also depends on the bounds of each variable-length rf_interface entry and its extension parameters, while version 1 requires space for the interface array and trailing rsp_2 structure.
Is there an observable indication that the vulnerable path was reached?
The malformed data can lead to reads of uninitialized slab memory that are later used in nci_init_complete_req(). The reported symptom is a KMSAN uninit-value warning.