Look up another CVE · open CVE-2024-47794 in the interactive tracker
CVE-2024-47794
bpf: Prevent tailcall infinite loop caused by freplace
Published 2025-01-11 (21 months ago) by the Linux kernel CNA. Subsystem include/linux. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-47794 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.5-1 | Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.5-1 | Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.5-1 | Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace. In an upcoming selftest, the attach target for entry_freplace of tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in entry_freplace leads to entry_tc. This results in an infinite loop: entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc. The problem arises because the tail_call_cnt in entry_freplace resets to zero each time entry_freplace is executed, causing the tail call mechanism to never terminate, eventually leading to a kernel panic. To fix this issue, the solution is twofold: 1. Prevent updating a program extended by an freplace program to a prog_array map. 2. Prevent extending a program that is already part of a prog_array map with an freplace program. This ensures that: * If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map. * If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program. Moreover, an extension program should not be tailcalled. As such, return -EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a prog_array map. Additionally, fix a minor code style issue by replacing eight spaces with a tab for proper formatting.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/linux/bpf.h
kernel/bpf/arraymap.c
kernel/bpf/core.c
kernel/bpf/syscall.c
kernel/bpf/trampoline.c
- What this is
- BPF [CORE]MAINTAINERS section matched on include/linux/bpf* · bpf@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_BPF|CONFIG_BPF_SYSCALL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switches
- CONFIG_BPF, CONFIG_BPF_SYSCALL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2025-01-11 (21 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.20%, higher than 9.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/linux
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.6 | 6.12.5 | 987aa730bad3 |
| 5.6 | 6.13 | d6083f040d5d |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The entire attack is built and triggered through the local `bpf(2)` syscall — two `BPF_PROG_LOAD` calls, a `BPF_LINK_CREATE` freplace attach, a `PROG_ARRAY` map update, and `BPF_PROG_TEST_RUN`. No network peer or remote input is involved, and no netdev attachment is required.
- AC:LAttack complexity, low
- The attacker constructs every component of the loop (target prog, its bpf2bpf subprog, the freplace extension, and the prog_array entry) and fires it deterministically; there is no race, no memory-layout dependency, and no state outside the attacker's control. Every invocation reproduces the runaway tail-call chain.
- PR:LPrivileges required, low
- Loading `BPF_PROG_TYPE_EXT` goes through `bpf_token_capable()` for CAP_BPF/CAP_NET_ADMIN/CAP_PERFMON, which grants only `ns_capable()`-level checks when a BPF token is delegated to a user namespace via bpffs `delegate_cmds`/`delegate_progs` — so a low-privileged container process with a delegated token can reach it, and no real init-namespace root is strictly needed.
- UI:NUser interaction, none
- The attacker loads, attaches, and executes the programs entirely on its own via `BPF_PROG_TEST_RUN` or by attaching the classifier and sending itself a packet. No victim action of any kind is required.
- S:UScope, unchanged
- The corruption and the crash both occur in the kernel's own stack within the same security authority; there is no VM, IOMMU, or sandbox boundary crossed.
- C:HConfidentiality impact, high
- The unbounded recursion is an out-of-bounds write past the kernel stack limit with attacker-chosen BPF stack contents; on builds without CONFIG_VMAP_STACK (e.g. KASAN_GENERIC configs, where `arch/Kconfig` disables it) the overflow spills into adjacent kernel memory, yielding a corruption primitive usable for disclosing kernel data.
- I:HIntegrity impact, high
- Same stack overflow gives an unbounded, attacker-controlled out-of-bounds write past the stack guard limit, which on non-VMAP_STACK configurations overwrites adjacent kernel structures and is leverageable for control-flow hijack; per guidance any OOB write scores High.
- A:HAvailability impact, high
- The commit states the tail-call mechanism "never terminate[s], eventually leading to a kernel panic" — the stack grows every cycle until it hits the guard page, producing an immediate double-fault panic (or silent corruption) within microseconds, and it can be re-triggered on every packet if the classifier is attached to a live interface.