CVE-2026-90159 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks
_bpf_setsockopt() and _bpf_getsockopt() call sock_owned_by_me() for full sockets, so these helpers expect the socket lock to be held.
BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sock_owned_by_me() warning by calling bpf_setsockopt() or bpf_getsockopt().
Disallow bpf_setsockopt() and bpf_getsockopt() for CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME.
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 Berkeley Packet Filter (BPF) subsystem provides a powerful mechanism for attaching programs to various kernel hooks, including cgroup operations related to network sockets. A specific vulnerability was identified within the interaction between BPF helper functions designed for socket options and the execution context of certain cgroup UNIX socket hooks. Specifically, the helpers _bpf_setsockopt() and _bpf_getsockopt() are implemented with an expectation that the caller holds the socket lock. This requirement is enforced through a call to sock_owned_by_me(), which checks if the current thread owns the socket's spinlock. If this condition is not met, the kernel triggers a warning or potentially leads to undefined behavior due to race conditions in accessing shared socket data structures.
The vulnerability arises because BPF programs attached to the CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME hooks are executed without acquiring the associated socket lock. These hooks are invoked during system calls that retrieve peer name information or local socket address details for UNIX domain sockets. When a BPF program running in this context attempts to invoke bpf_setsockopt() or bpf_getsockopt(), it violates the locking contract required by these helper functions. This mismatch between the execution context and the helper function's expectations creates a scenario where the kernel detects an invalid state, potentially leading to denial of service through kernel warnings or crashes if not properly handled by the surrounding error checking logic.
From a technical perspective, this flaw represents a classic case of improper locking in concurrent programming environments. The absence of proper synchronization primitives when accessing shared resources leads to race conditions and integrity violations within the kernel's memory management subsystems. In terms of industry standards, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). Furthermore, it can be mapped to MITRE ATT&CK techniques related to privilege escalation or denial of service via exploitation of software vulnerabilities, specifically under the tactic of execution if an attacker can trigger the BPF program through crafted socket operations.
The operational impact of this vulnerability allows for potential disruption of network services running on affected systems. An unprivileged user with access to create UNIX sockets and attach eBPF programs could potentially cause kernel warnings or instability by triggering these helper functions within the specified cgroup hooks. While modern kernels often mitigate some impacts through strict permission checks, the underlying race condition remains a significant security risk that compromises system stability and reliability.
To address this issue, developers have implemented a restriction disallowing bpf_setsockopt() and bpf_getsockopt() calls when executed from BPF programs attached to CGROUP_UNIX_GETPEERNAME or CGROUP_UNIX_GETSOCKNAME hooks. This mitigation ensures that the locking contract is respected by preventing access to these specific helper functions in contexts where the socket lock is not held. System administrators should ensure their kernels are updated with this patch applied. Additionally, developers writing BPF programs for UNIX cgroup hooks must adhere to the documented constraints regarding available helper functions and synchronization requirements to maintain system integrity.