CVE-2026-80794
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's NFC handling could let local programs see random leftover data from inside the kernel.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Uninitialized stack memory in RF discover/activated NTF handlers is passed to nci_add_new_protocol() which reads and copies portions of it (nfca_poll nfcid1 etc.) into ndev->targets, later exposed to userspace via NFC_CMD_GET_TARGET, causing kernel information disclosure.
Why it matters to the business
Local users or processes with NFC access could read uninitialized kernel memory, potentially exposing sensitive data like stack contents or prior kernel operations. Low urgency given low EPSS and absence from KEV.
How an attack unfolds
An attacker with ability to trigger or spoof NFC RF notifications sends a notification with zero rf_tech_specific_params_len, leaving the union uninit. Handlers pass it without init, nci_add_new_protocol reads uninit values for memcpy lengths and data, leaking to userspace targets list.
How to fix it
Update to a Linux kernel version that includes the fix for zero-initializing the on-stack notifications in nci_rf_discover_ntf_packet and nci_rf_intf_activated_ntf_packet.
How to confirm the fix worked
Verify kernel source has the zero-initialization patch; test with crafted NFC notifications to ensure no KMSAN reports.
Typical attack path
- Trigger NFC notification with zero-length tech params
- Kernel parses without initializing union
- nci_add_new_protocol copies uninit data based on nfca_poll->nfcid1_len
- Data exposed via NFC_CMD_GET_TARGET to userspace
How to detect it
Look for KMSAN reports mentioning nci_add_new_protocol and uninit-value in NFC paths; check logs for NFC_CMD_GET_TARGET calls returning unexpected data.
What your security team should do
- Apply kernel updates containing the fix
- Restrict NFC access to trusted processes if possible
- Monitor for KMSAN or similar sanitizer reports in NFC paths
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|