CVE-2026-80794

In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: fix uninit-value in the RF discover/activated NTF handlers

nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each

parse a notification into an on-stack struct (nci_rf_discover_ntf /

nci_rf_intf_activated_ntf) that is not initialised. The RF

technology-specific parameters are only extracted when

rf_tech_specific_params_len is non-zero, so a notification that reports a

zero length leaves the rf_tech_specific_params union uninitialised - and

both handlers then pass it to nci_add_new_protocol(), which reads it:

- discover: nci_add_new_target() -> nci_add_new_protocol();

- activated: nci_target_auto_activated() -> nci_add_new_protocol().

nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch

condition and a memcpy() length and copies nfcid1/sens_res/sel_res into

ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET.

BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0

nci_add_new_protocol+0x624/0x6c0

nci_ntf_packet+0x25b2/0x3c30

nci_rx_work+0x318/0x5d0

process_scheduled_works+0x84b/0x17a0

worker_thread+0xc10/0x11b0

kthread+0x376/0x500

Local variable ntf.i created at:

nci_ntf_packet+0xbc2/0x3c30

Zero-initialise both on-stack notifications so the union reads back as

zero when no technology-specific parameters are present.