CVE-2026-90223 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed:
- For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made "service_name_len = length - 1" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3]
without a length check.
A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP.
Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2).
Found by 0sec automated security-research tooling (https://0sec.ai).
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's Near Field Communication subsystem contains a critical vulnerability within the Logical Link Control Protocol implementation, specifically in the service name list parsing logic. This flaw arises from insufficient boundary checks when processing Type-Length-Value structures during the reception of Service Discovery Request and Response frames. The function nfc_llcp_recv_snl processes incoming data by iterating through TLV entries using an offset derived directly from the socket buffer length without validating that sufficient data exists for each individual component read. This lack of rigorous input validation creates multiple pathways for memory corruption, including integer underflows and out-of-bounds reads, which can be exploited by any nearby NFC device capable of establishing a link via NFC-DEP protocols without requiring authentication.
The technical root cause involves several distinct arithmetic and boundary errors within the parsing loop. First, if an incoming frame is shorter than the LLCP header size, the calculation for TLV length results in an underflow due to unsigned integer wrap-around, leading to invalid memory access patterns. Second, the code reads two-byte headers comprising type and length fields without verifying that at least two bytes remain available in the buffer before performing the read operation. Third, a declared TLV length may exceed the actual remaining data in the socket buffer, causing subsequent operations to access memory beyond the allocated region. Specifically, when processing an SDREQ frame with a zero-length field, the calculation service_name_len = length - 1 triggers a size_t underflow because unsigned arithmetic wraps around to a maximum value. This erroneous large value is then passed to strncmp and nfc_llcp_sock_from_sn functions, resulting in out-of-bounds reads that can leak kernel memory contents or cause system instability depending on what data resides at those unauthorized addresses.
The operational impact of this vulnerability allows for remote information disclosure and potential denial of service conditions without any prior authentication. Since LLCP link activation occurs automatically after NFC-DEP connection establishment, an attacker with physical proximity to the target device can craft maliciously formatted NFC frames that trigger these parsing errors. The out-of-bounds read in particular poses a significant risk as it may expose sensitive kernel memory structures or stack data to the connected peer device. This capability effectively bypasses standard security boundaries by leveraging the trust placed in the automatic link activation process and the assumption that incoming protocol messages are well-formed. Such vulnerabilities align with CWE-125 Out-of-bounds Read and CWE-190 Integer Overflow or Wraparound, representing classic memory safety issues prevalent in low-level system code like kernel drivers.
Mitigation strategies focus on enforcing strict bounds checking during TLV iteration to prevent any access beyond the allocated socket buffer boundaries. The resolution involves replacing offset-based indexing with pointer arithmetic bounded by skb_tail_pointer over linear data segments, ensuring that every read operation respects the actual available memory limits. Explicit length validations are added for SDREQ frames requiring a minimum length of one byte and SDRES frames requiring exactly two bytes to prevent underflow scenarios during subsequent calculations. These changes ensure that each TLV header is verified before access and that declared lengths do not exceed remaining buffer capacity. Security practitioners should apply the latest kernel updates containing these patches immediately, as they address fundamental input validation failures in a network-facing subsystem accessible via physical proximity attacks. This incident underscores the importance of rigorous boundary checks in protocol parsers and highlights how automated security research tools can identify subtle arithmetic errors that lead to severe memory safety violations. The vulnerability is categorized under ATT&CK techniques related to initial access through local or nearby devices, emphasizing the need for defense-in-depth measures even against physically proximate threats.