CVE-2026-80800

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).