CVE-2026-98482

Unknown

Last modified

CVE-2026-98482 is a vulnerability of currently unknown severity. In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom.

Description

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control. Guard the read with pskb_may_pull(), as commit 95674f506c63 ("nfc: llcp: reject PDUs shorter than the LLCP header") did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 3afdbebfee2ef7e9510880868cfb482cbffe6836; >= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 9b4086eb67a9a3b1ce69fef1b6793827363703ce; >= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 51b6d73373589abb9de4d84767b0db1bc8d395d9; >= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 066205553a0106565bcede934f5721c25ebd6e4e; >= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 18f60ee882403d5b48097f5f6ae45f794e4cc643; >= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 810f204ef8f61f0c930cf6b3280050b3ee6a8ae7; >= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 744e61bd06188d8bb068c26a461c252f242b05c9; >= d646960f7986fefb460a2b062d5ccc8ccfeacc3a, < 273f9d667cde649f8de9d72b1303cc2f4b658c50
LinuxLinux3.3

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-98482?
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control. Guard the read with pskb_may_pull(), as commit 95674f506c63 ("nfc: llcp: reject PDUs shorter than the LLCP header") did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.
How severe is CVE-2026-98482?
Severity scoring for CVE-2026-98482 is pending analysis.
How do I fix CVE-2026-98482?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-98482?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST