CVE-2026-74689 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net/atm: fix slab-out-of-bounds read in vcc_setsockopt()
vcc_setsockopt() contained an ineffective optlen check: if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname)) return -EINVAL;
If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller passed a mismatched level), the length check optlen != __SO_SIZE(optname) was short-circuited and bypassed. Execution then fell through to switch(optname), calling copy_from_sockptr() assuming optval contained sufficient space.
Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(), this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the expected structure size.
Fix this by using copy_safe_from_sockptr(), which unconditionally validates that optlen is at least the expected size before copying. Also change the local 'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches its sizeof(int) ABI encoding on 64-bit systems.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in the Linux kernel within the net/atm subsystem involves a critical input validation flaw in the vcc_setsockopt function, which handles socket option settings for Asynchronous Transfer Mode network interfaces. This issue manifests as a slab-out-of-bounds read, allowing an attacker with local access to potentially leak sensitive kernel memory contents or cause a denial of service through a system crash. The root cause lies in the logic governing how input parameters are validated before being processed by the kernel. Specifically, the function employs a conditional check that is intended to verify if the length of the provided option data matches the expected size for that specific socket option. However, this validation mechanism contains a logical error due to short-circuit evaluation behavior in C programming language constructs.
The flawed code structure checks two conditions using a logical AND operator: first verifying if the protocol level matches expectations via __SO_LEVEL_MATCH, and second ensuring the provided length optlen equals the expected size defined by __SO_SIZE. When an attacker provides a socket option name that does not match the expected protocol level, the first condition evaluates to false. Due to short-circuit evaluation rules, the entire expression becomes false immediately without evaluating the second part of the check. Consequently, the critical boundary validation for optlen is bypassed entirely. Execution then proceeds directly to a switch statement based on the option name, where the kernel attempts to copy data from user space into kernel memory using copy_from_sockptr(). This function assumes that the provided buffer contains sufficient data corresponding to the expected structure size, leading to an out-of-bounds read when the actual input length is insufficient.
Even in scenarios where the protocol level matches and the initial check passes, a secondary vulnerability vector exists related to dynamic modification of parameters by cgroup BPF filters. A privileged user or process with appropriate capabilities can attach a Berkeley Packet Filter rule that modifies socket options during execution. If such a filter shrinks the optlen value after the initial validation but before the actual data copy operation occurs, the kernel proceeds with copying more bytes than are actually available in the source buffer. Since copy_from_sockptr relies on standard memcpy operations for kernel pointers, this discrepancy results in reading memory beyond the allocated slab object boundaries. This behavior is detectable by Kernel Address Sanitizer and represents a classic out-of-bounds read vulnerability that can compromise system stability and security integrity.
From an industry standards perspective, this flaw aligns with CWE-20 Improper Input Validation, as the application fails to adequately verify user-supplied input before processing it. Additionally, because the vulnerability allows for reading arbitrary kernel memory contents through crafted socket options, it relates closely to CWE-125 Out-of-bounds Read. In terms of attack tactics, this could be leveraged in an information disclosure scenario within the MITRE ATT&CK framework, specifically under techniques involving unauthorized access to system resources or data exfiltration from protected processes. The exploitation typically requires local user privileges and specific network configuration contexts, limiting its broad applicability but increasing severity for targeted attacks against systems handling ATM traffic.
The resolution implemented by the Linux kernel maintainers addresses these issues through two primary technical changes. First, the unsafe copy_from_sockptr function is replaced with copy_safe_from_sockptr. This updated function unconditionally validates that the provided length optlen meets or exceeds the expected structure size before attempting any memory copy operations. By enforcing this check regardless of protocol level matching outcomes, the short-circuit bypass vulnerability is eliminated entirely. Second, the data type for the local variable value used in handling SO_SETCLP options was changed from unsigned long to int. This adjustment ensures correct Application Binary Interface encoding on 64-bit systems, preventing potential size mismatches that could otherwise lead to similar validation failures or memory corruption issues during option processing.
Mitigation strategies involve applying the latest kernel patches that include these fixes for affected distributions and environments utilizing ATM networking support. System administrators should ensure regular updates are applied to maintain protection against such low-level input validation flaws. For organizations unable to patch immediately, restricting network interface configurations to disable unnecessary ATM protocols can reduce the attack surface. Monitoring system logs for KASAN reports or unusual memory access patterns may also aid in detecting attempted exploitation of this vulnerability before significant damage occurs. Continuous monitoring and adherence to secure coding practices that emphasize rigorous boundary checks remain essential defenses against similar classes of kernel vulnerabilities.