Fixed
Created: Oct 21, 2024
Updated: Oct 26, 2025
Resolved Date: Oct 9, 2025
Found In Version: 10.22.33.1
Severity: Standard
Applicable for: Wind River Linux LTS 22
Component/s: Kernel
In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent tail call between progs attached to different hooksbpf progs can be attached to kernel functions, and t
he attached functionscan take different parameters or return different return values. Ifprog attached to one kernel function tail calls prog attached to anotherkernel function, the ct
x access or return value verification could bebypassed.For example, if prog1 is attached to func1 which takes only 1 parameterand prog2 is attached to func2 which takes two parameters
. Since verifierassumes the bpf ctx passed to prog2 is constructed based on func2'sprototype, verifier allows prog2 to access the second parameter fromthe bpf ctx passed to it. The pr
oblem is that verifier does not preventprog1 from passing its bpf ctx to prog2 via tail call. In this case,the bpf ctx passed to prog2 is constructed from func1 instead of func2,that
is, the assumption for ctx access verification is bypassed.Another example, if BPF LSM prog1 is attached to hook file_alloc_security,and BPF LSM prog2 is attached to hook bpf_lsm_audi
t_rule_known. Verifierknows the return value rules for these two hooks, e.g. it is legal forbpf_lsm_audit_rule_known to return positive number 1, and it is illegalfor file_alloc_secur
ity to return positive number. So verifier allowsprog2 to return positive number 1, but does not allow prog1 to returnpositive number. The problem is that verifier does not prevent pr
og1from calling prog2 via tail call. In this case, prog2's return value 1will be used as the return value for prog1's hook file_alloc_security.That is, the return value rule is bypass
ed.This patch adds restriction for tail call to prevent such bypasses.
========Wind River Notice========
The default WindRiver Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.