data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2024-47794 in the interactive tracker

CVE-2024-47794

bpf: Prevent tailcall infinite loop caused by freplace

7.8 EPSS 0.2% AV:L

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

ReleaseStatus VersionWhat this means
Debian 12bookwormvulnerable6.1.190-1No 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 13trixiefixed6.12.5-1Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed6.12.5-1Update the kernel and reboot. Fixed in 6.12.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed6.12.5-1Update 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

IntroducedFixed inCommit
5.66.12.5987aa730bad3
5.66.13d6083f040d5d

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.