CVE-2026-90327 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
phonet: pep: do not write beyond optlen in getsockopt
pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer.
Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.
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 vulnerability identified in the phonet protocol endpoint peer (pep) subsystem involves a classic out-of-bounds write condition within the getsockopt implementation. This flaw arises from an inconsistency between how the buffer size is validated and how data is subsequently written back to user space. Specifically, the function pep_getsockopt correctly utilizes min_t to clamp the reported length based on the caller's provided optlen parameter, ensuring that userspace receives a value no larger than what they allocated. However, the actual mechanism used to transfer this integer value from kernel space to user space relies on put_user with an explicit size of sizeof(int). This function unconditionally writes four bytes regardless of whether the original buffer was smaller, leading to a heap or stack overflow depending on where optval points if it is less than four bytes.
This technical flaw represents a significant security risk as it allows for memory corruption in user space applications that invoke this socket option with small buffers. An attacker who can control the parameters passed to getsockopt could potentially overwrite adjacent memory structures, leading to arbitrary code execution or denial of service conditions. The vulnerability is particularly insidious because standard bounds checking appears present due to the clamping logic, but the subsequent write operation bypasses these safeguards by ignoring the actual buffer size constraint during the data transfer phase.
From a classification perspective, this issue aligns with CWE-120 Buffer Copy without Checking Size of Input Classic and CWE-787 Out-of-bounds Write in the Common Weakness Enumeration framework. In terms of attack vectors, it falls under ATT&CK technique T1059 Command and Scripting Interpreter if exploited via scriptable interfaces or more broadly as a local privilege escalation vector if kernel memory is compromised through subsequent exploitation chains involving this user-space corruption. The phonet protocol itself is often used in specialized telecommunications contexts, making the potential impact relevant to industrial control systems and mobile network infrastructure components that rely on Linux-based kernels for connectivity management.
The resolution involves replacing the fixed-size put_user call with copy_to_user bounded by the actual optlen value provided by the caller. This ensures that only the number of bytes explicitly requested or permitted are written, thereby maintaining strict alignment between the reported length and the physical memory access operations. Developers should audit similar socket option implementations across the kernel to ensure consistent use of size-aware copying functions rather than fixed-size writes when dealing with variable-length user buffers. Regular static analysis tools configured to detect mismatched buffer sizes in system calls can help prevent such discrepancies in future code changes, reinforcing defense-in-depth strategies against memory corruption vulnerabilities.