CVE-2026-90226 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: avoid userspace overflow on invalid optlen
nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames.
Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel’s Near Field Communication subsystem contains a critical buffer overflow vulnerability within the NFC Link Layer Control Protocol implementation, specifically in the nfc_llcp_getsockopt function. This flaw arises from an improper handling of user-supplied length parameters when retrieving socket options via the getsockopt system call. The core technical issue stems from how the kernel processes the optval pointer and the associated optlen parameter provided by userspace applications. When a process invokes this interface to query NFC LLCP configuration details, the kernel code casts the optval argument to a u32 __user pointer type before passing it to put_user for data transfer back to the application space. This casting operation assumes that exactly four bytes will be written regardless of what length value was actually supplied by the caller in the optlen field.
The vulnerability is exacerbated by insufficient validation logic within the function body. While the code does employ a min_t macro to clamp the len variable returned to userspace, ensuring that the reported size does not exceed sizeof u32 or the requested length, this check only affects the metadata sent back about how much data was written. It fails to constrain the actual memory write operation itself. Consequently, if an attacker supplies an optlen value less than four bytes but greater than zero, the kernel proceeds with writing a full thirty-two-bit integer into a buffer that is too small to accommodate it. This results in a heap-based or stack-based buffer overflow depending on where the user-provided buffer resides in memory, allowing for potential out-of-bounds writes beyond the intended destination boundaries.
This flaw violates the fundamental contract of the getsockopt system call, which mandates that kernels must not write more data than specified by the optlen parameter provided by the caller. The vulnerability affects all five supported option names within this subsystem, meaning any application attempting to retrieve these specific NFC LLCP settings is susceptible to triggering the overflow if manipulated with crafted input values. An attacker could exploit this condition to corrupt adjacent memory structures, potentially leading to arbitrary code execution, privilege escalation from unprivileged user space to kernel root privileges, or denial of service through system crashes caused by memory corruption and subsequent segmentation faults in critical kernel paths.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input Classic buffer overflow and CWE-273 Improper Check for Unusual or End Conditions leading to incorrect handling of edge cases like small length values. In the context of the MITRE ATT&CK framework, this represents a technique related to exploitation via memory corruption, specifically targeting kernel space through improper input validation during system call processing. The lack of rigorous bounds checking on user-controlled parameters before performing fixed-size writes is a common pattern in legacy kernel code that requires immediate remediation to prevent remote or local privilege escalation attacks.
To mitigate this risk, the Linux kernel maintainers have implemented a strict length check at the beginning of the nfc_llcp_getsockopt function. The fix explicitly rejects any invocation where optlen is less than sizeof u32, which equals four bytes for thirty-two-bit unsigned integers. Crucially, because the len variable is declared as an integer type rather than an unsigned size_t, a simple comparison against zero could be bypassed by negative values due to implicit type promotion rules in C programming languages. Negative optlen values would be promoted to large positive numbers when compared with size types, effectively slipping past standard lower-bound checks. Therefore, the patch introduces an explicit check for len being less than zero before performing any further comparisons or operations. This ensures that both underflow conditions caused by small positive lengths and overflow-like behaviors resulting from negative inputs are caught early in the execution path.
System administrators should ensure their Linux kernels are updated to versions containing this specific NFC LLCP patch. Since this vulnerability exists within a subsystem primarily used for Near Field Communication hardware interactions, it may be less frequently targeted than network stack vulnerabilities but remains dangerous due to its kernel-level impact and potential for local privilege escalation. Automated fuzzing tools targeting socket option interfaces should also be employed to detect similar patterns in other parts of the kernel where getsockopt implementations might suffer from analogous insufficient input validation logic. Continuous monitoring for anomalous memory access patterns or crashes related to NFC subsystems can help identify exploitation attempts before they result in full system compromise.