CVE-2026-80794: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: fix uninit-value in the RF discover/activated NTF handlers
ncirfdiscoverntfpacket() and ncirfintfactivatedntfpacket() each parse a notification into an on-stack struct (ncirfdiscoverntf / ncirfintfactivatedntf) that is not initialised. The RF technology-specific parameters are only extracted when rftechspecificparamslen is non-zero, so a notification that reports a zero length leaves the rftechspecificparams union uninitialised - and both handlers then pass it to nciaddnewprotocol(), which reads it:
- discover: nciaddnewtarget() -> nciaddnewprotocol(); - activated: ncitargetautoactivated() -> nciaddnewprotocol().
nciaddnewprotocol() uses nfcapoll->nfcid1len as both a branch condition and a memcpy() length and copies nfcid1/sensres/selres into ndev->targets, which is later exposed to user space via NFCCMDGETTARGET.
BUG: KMSAN: uninit-value in nciaddnewprotocol+0x624/0x6c0 nciaddnewprotocol+0x624/0x6c0 ncintfpacket+0x25b2/0x3c30 ncirxwork+0x318/0x5d0 processscheduledworks+0x84b/0x17a0 workerthread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: ncintfpacket+0xbc2/0x3c30
Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.
Affected Software
Event History
Frequently Asked Questions
What runtime condition causes the uninitialized data to be used?
An RF discover or RF interface activated notification must report a zero-length RF technology-specific parameter field. In that case, the on-stack parameter union is not populated before nci_add_new_protocol() reads it.
Where can the uninitialized data be exposed?
nci_add_new_protocol() can use the uninitialized nfca_poll nfcid1_len value as a memcpy length when populating ndev->targets. The resulting target data can later be exposed to user space through NFC_CMD_GET_TARGET.
Which notification paths are involved?
Both the RF discover notification path, through nci_add_new_target(), and the RF interface activated notification path, through nci_target_auto_activated(), reach nci_add_new_protocol() with the potentially uninitialized parameters.
Is there an available diagnostic signal for this issue?
The provided report shows KMSAN detecting an uninitialized-value access in nci_add_new_protocol(). A KMSAN-enabled kernel may therefore identify the issue when the affected notification handling path is exercised.