From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-98044: bpf: Reject legacy packet loads from callbacks
Date: Fri, 25 Sep 2026 12:25:46 +0200 [thread overview]
Message-ID: <2026092531-CVE-2026-98044-efcb@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject legacy packet loads from callbacks
check_ld_abs() models a failed BPF_LD_ABS or BPF_LD_IND in a
subprogram as an implicit return with R0 set to zero. It calls
prepare_func_exit() to explore this synthesized path.
When the load is reached directly from a synchronous callback,
prepare_func_exit() enforces the callback return contract and marks R0
precise. R0 is not derived from a real instruction on this path, so
precision backtracking reaches the callback call with R0 still requested
and triggers the "callback unexpected regs" verifier bug. A privileged
program loader can therefore cause a verifier warning and an -EFAULT
BPF_PROG_LOAD.
These legacy packet-load instructions are deprecated. Reject them from
callbacks rather than complicating their implicit-return model. Check all
active frames before constructing the implicit return so nested static
subprograms cannot hide the callback context.
Global functions are verified independently with a fresh frame zero, so
an active-frame check cannot identify a global function called from a
callback. Also check the complete subprogram call graph during stack-depth
validation and reject a function containing a legacy load when any caller
is a callback. This covers global and static descendants without making
has_ld_abs transitive, preserving its per-function BTF return-type check.
Ordinary uses outside callbacks remain supported.
The Linux kernel CVE team has assigned CVE-2026-98044 to this issue.
Affected and fixed versions
===========================
Issue introduced in 6.18.42 with commit ce01a4e5cfac7adbe0be565f90cd32ecbb2f8337 and fixed in 6.18.53 with commit 3484a99303912db62428494a9061212049027e57
Issue introduced in 7.1 with commit ee861486e377edc55361c08dcbceab3f6b6577bd and fixed in 7.2.7 with commit bc489c0c9b8c86bd7fac42cfd1bb152f042fca56
Issue introduced in 7.1 with commit ee861486e377edc55361c08dcbceab3f6b6577bd and fixed in 7.3-rc2 with commit e7d28823c662128caae63f14e16bd394916c139b
Issue introduced in 5.10.265 with commit 928d354ae3557e8f755a227e67be88034eb3cd7f
Issue introduced in 5.15.216 with commit 8a800497d9f6c2ec9c2c1ba7b71d0ac2ea7f7bbe
Issue introduced in 6.1.183 with commit de1055e7f9e67af32b1f3376066272b04e5223c0
Issue introduced in 6.6.148 with commit 37ad2bb11e9de92cb7b94548705eeedd87f7d392
Issue introduced in 6.12.101 with commit 8674e2db06cff6b50f2216eed9a761d15425bb34
Issue introduced in 7.0.10 with commit d846d83bdacbd8f14fc45c63b8c1d22608452e1c
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-98044
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
kernel/bpf/verifier.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/3484a99303912db62428494a9061212049027e57
https://git.kernel.org/stable/c/bc489c0c9b8c86bd7fac42cfd1bb152f042fca56
https://git.kernel.org/stable/c/e7d28823c662128caae63f14e16bd394916c139b
reply other threads:[~2026-09-25 10:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026092531-CVE-2026-98044-efcb@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.