CVE-2026-80800 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: bound the connect_sn TLV walk to the skb
Commit 27256cdb290e ("nfc: llcp: bound SNL TLV parsing to the skb and add length checks") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 ("nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn().
nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as "skb->len - LLCP_HEADER_SIZE" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer.
nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard.
Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the
size_t underflow for short frames.
Found by 0sec automated security-research tooling (https://0sec.ai).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel's Near Field Communication subsystem contains a critical out-of-bounds read vulnerability within the Logical Link Control Protocol implementation, specifically in the nfc_llcp_connect_sn function. This flaw arises from an unbounded traversal of Type-Length-Value lists during the parsing of service names associated with connection requests. While previous commits addressed similar issues in other parsers such as nfc_llcp_recv_snl and nfc_llcp_parse_gb_tlv by bounding their walks to the socket buffer limits, this specific parser remained unchecked. The function iterates through TLV structures without verifying that the two-byte header consisting of type and length fields remains within the allocated memory boundaries or that the declared length does not exceed the remaining data in the packet. This oversight allows an attacker to craft malicious packets that cause the kernel to read beyond the end of the buffer, potentially exposing sensitive kernel memory contents to a local or nearby remote entity depending on the NFC interface configuration.
The operational impact of this vulnerability is significant due to its reachability and ease of exploitation. The vulnerable function nfc_llcp_connect_sn is invoked by nfc_llcp_recv_connect and nfc_llcp_recv_cc, which handle incoming CONNECT and Connection Complete Protocol Data Units respectively. These PDUs are part of the standard NFC-DEP communication flow where LLCP link activation occurs automatically without requiring explicit authentication from a user or application layer. Consequently, an attacker with physical proximity to the device can trigger this code path simply by initiating an NFC connection attempt. Furthermore, the dispatcher nfc_llcp_rx_skb applies no minimum length guard before processing these frames, allowing even malformed short packets to reach the vulnerable logic. The calculation of tlv_array_len as skb->len minus LLCP_HEADER_SIZE is performed using size_t arithmetic; if a received frame is shorter than the expected header, this subtraction results in an integer underflow, producing a massive positive length value that causes the subsequent loop to run far past the buffer boundary.
From a security classification perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read and CWE-190 Integer Overflow or Wraparound due to the size_t underflow issue. The exploitation vector is classified as adjacent network access within the MITRE ATT&CK framework, specifically leveraging Local Network Services such as NFC protocols for initial access. The lack of authentication requirements in the LLCP link activation phase further exacerbates the risk, allowing unauthenticated actors to probe and potentially exploit this flaw. Successful exploitation could lead to information disclosure through kernel memory leaks or, if combined with other vulnerabilities, potentially facilitate arbitrary code execution via subsequent use of the invalid pointer returned by nfc_llcp_connect_sn which is consumed by memcmp in nfc_llcp_sock_from_sn.
The resolution involves modifying the nfc_llcp_connect_sn function to strictly bound the TLV list walk using skb_tail_pointer as the upper limit for memory access. Each declared length within a TLV structure must be validated before being used to advance the pointer, ensuring that no read operation exceeds the available data in the socket buffer. The implementation should start the traversal at &skb->data[LLCP_HEADER_SIZE] and compare against the tail pointer rather than relying on potentially underflowed size calculations. This approach mirrors the defensive patterns already established in other parts of the NFC LLCP subsystem, such as nfc_llcp_recv_snl, thereby ensuring consistency across the codebase. By enforcing these bounds checks and validating lengths prior to use, the kernel prevents out-of-bounds memory access and eliminates the integer underflow condition that previously allowed for excessive buffer traversal.