Linux kernel BPF: freplace program in a tail-call chain resets tail_call_cnt and panics the kernel

CVSS 5.5CVE-2024-47794Kernel, userspace & hypervisorcurated

Impact

A BPF extension (freplace) program attached inside a tail-call chain resets tail_call_cnt on every entry, so the usual tail-call limit never fires and the chain loops until the kernel panics. The fix forbids the two combinations that create the loop: updating an freplace-extended program into a prog_array, and extending a program already in a prog_array; BPF_PROG_TYPE_EXT programs are also rejected from prog_array maps. Operators who run CNI, service-mesh or observability agents that load their own BPF programs are the exposed population - a panic takes the whole node and every GPU job on it, not one container. Availability only.

Who can reach it

Local, requires the ability to load and attach BPF programs - CAP_BPF plus the attach capability, i.e. a privileged agent or a container granted BPF access. Not reachable by an ordinary unprivileged tenant pod.

What to do

Update to a stable kernel carrying the linked fix commits and reboot the node; there is no runtime mitigation other than not granting BPF load/attach rights to workloads. The record lists commits only, no vendor fixed-version string - map them onto the stable branch you track.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-47794 https://git.kernel.org/stable/c/d6083f040d5d8f8d748462c77e90547097df936e https://git.kernel.org/stable/c/987aa730bad3e1ef66d9f30182294daa78f6387d https://git.kernel.org/stable/c/f8ba0d22afa613b280fc40fcf6ae99f73c7b36e6

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.