CVE-2026-90159: bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disallow bpf{g,s}etsockopt() in cgroup UNIX getname hooks
bpfsetsockopt() and bpfgetsockopt() call sockownedbyme() for full sockets, so these helpers expect the socket lock to be held.
BPFCGROUPUNIXGETPEERNAME and BPFCGROUPUNIXGETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sockownedbyme() warning by calling bpfsetsockopt() or bpfgetsockopt().
Disallow bpfsetsockopt() and bpfgetsockopt() for CGROUPUNIXGETPEERNAME and CGROUPUNIXGETSOCKNAME.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disallow bpf_setsockopt() and bpf_getsockopt() for cgroup hook BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME.
Linux kernel BPF cgroup UNIX getname hooks bpf_setsockopt()/bpf_getsockopt() allowance for BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME = disallow
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
A BPF program must be attached to either the CGROUP_UNIX_GETPEERNAME or CGROUP_UNIX_GETSOCKNAME hook and call bpf_setsockopt() or bpf_getsockopt(). Those hooks run without acquiring the socket lock expected by the helpers.
What is the observed impact when the issue is triggered?
The program can trigger the sock_owned_by_me() warning when either helper is called from one of the affected hooks.
What can be done before applying the resolved kernel change?
Do not use bpf_setsockopt() or bpf_getsockopt() in BPF programs attached to the affected CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME hooks. The resolved change disallows those helper calls for these hooks.