CVE-2026-90359: bpf: Reject >8 byte return values on return-reading trampoline paths
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject >8 byte return values on return-reading trampoline paths
btfdistillfuncproto() builds the function model used for the fentry/fexit/fmodret/fsession trampolines and structops. It has accepted a 16-byte int128 return value since the trampoline was introduced: gettypesize() returns the integer's type size, and the return-type check only rejected ret < 0.
But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. structops trampolines have the same limitation.
This affects the attach types that read the target's return value: fexit, fmodret and fsession (plus the multi variants of fexit and fsession), and structops. fentry/fentrymulti run before the target returns and are unaffected.
Reject a >8 byte return value for these attach types in bpfcheckattachtarget() and bpfcheckattachbtfidmulti(), and for structops in bpfstructopsdescinit().
Affected Software
Event History
Frequently Asked Questions
Which BPF attachment types are affected?
The affected return-reading attachment types are fexit, fmod_ret, and fsession, including the fexit_multi and fsession_multi variants, as well as struct_ops. fentry and fentry_multi are unaffected because they run before the target function returns.
What conditions are required for the return-value corruption to occur?
A BPF program must attach through an affected trampoline path to a target function that returns a value larger than 8 bytes, such as a 16-byte __int128. The trampoline preserves only 8 bytes of the target return value, leaving the remaining portion unsaved and unrestored.
How can this issue be identified in an existing BPF deployment?
Review affected fexit, fmod_ret, fsession, multi-attach, and struct_ops attachments and identify whether their target function prototypes return values larger than 8 bytes. Attachments to functions with 16-byte return values are the relevant cases described.
What is the mitigation if the fix cannot be deployed immediately?
Avoid attaching affected return-reading BPF programs or struct_ops trampolines to functions with return values larger than 8 bytes. fentry and fentry_multi do not read a target return value and are not affected by this limitation.