Message-ID: <2025120937-CVE-2022-50650-fbae@gregkh>
Date: Tue,  9 Dec 2025 09:01:51 +0900
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50650: bpf: Fix reference state management for synchronous callbacks

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix reference state management for synchronous callbacks

Currently, verifier verifies callback functions (sync and async) as if
they will be executed once, (i.e. it explores execution state as if the
function was being called once). The next insn to explore is set to
start of subprog and the exit from nested frame is handled using
curframe > 0 and prepare_func_exit. In case of async callback it uses a
customized variant of push_stack simulating a kind of branch to set up
custom state and execution context for the async callback.

While this approach is simple and works when callback really will be
executed only once, it is unsafe for all of our current helpers which
are for_each style, i.e. they execute the callback multiple times.

A callback releasing acquired references of the caller may do so
multiple times, but currently verifier sees it as one call inside the
frame, which then returns to caller. Hence, it thinks it released some
reference that the cb e.g. got access through callback_ctx (register
filled inside cb from spilled typed register on stack).

Similarly, it may see that an acquire call is unpaired inside the
callback, so the caller will copy the reference state of callback and
then will have to release the register with new ref_obj_ids. But again,
the callback may execute multiple times, but the verifier will only
account for acquired references for a single symbolic execution of the
callback, which will cause leaks.

Note that for async callback case, things are different. While currently
we have bpf_timer_set_callback which only executes it once, even for
multiple executions it would be safe, as reference state is NULL and
check_reference_leak would force program to release state before
BPF_EXIT. The state is also unaffected by analysis for the caller frame.
Hence async callback is safe.

Since we want the reference state to be accessible, e.g. for pointers
loaded from stack through callback_ctx's PTR_TO_STACK, we still have to
copy caller's reference_state to callback's bpf_func_state, but we
enforce that whatever references it adds to that reference_state has
been released before it hits BPF_EXIT. This requires introducing a new
callback_ref member in the reference state to distinguish between caller
vs callee references. Hence, check_reference_leak now errors out if it
sees we are in callback_fn and we have not released callback_ref refs.
Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2
etc. we need to also distinguish between whether this particular ref
belongs to this callback frame or parent, and only error for our own, so
we store state->frameno (which is always non-zero for callbacks).

In short, callbacks can read parent reference_state, but cannot mutate
it, to be able to use pointers acquired by the caller. They must only
undo their changes (by releasing their own acquired_refs before
BPF_EXIT) on top of caller reference_state before returning (at which
point the caller and callback state will match anyway, so no need to
copy it back to caller).

The Linux kernel CVE team has assigned CVE-2022-50650 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.13 with commit 69c087ba6225b574afb6e505b72cb75242a3d844 and fixed in 5.15.75 with commit 4ed5155043c97ac8912bcf67331df87c833fb067
	Issue introduced in 5.13 with commit 69c087ba6225b574afb6e505b72cb75242a3d844 and fixed in 5.19.17 with commit caa176c0953cdfd5ce500fb517ce1ea924a8bc4c
	Issue introduced in 5.13 with commit 69c087ba6225b574afb6e505b72cb75242a3d844 and fixed in 6.0.3 with commit aed931fd3b6e28f19cc140ff90aa5046ee2aa4e1
	Issue introduced in 5.13 with commit 69c087ba6225b574afb6e505b72cb75242a3d844 and fixed in 6.1 with commit 9d9d00ac29d0ef7ce426964de46fa6b380357d0a

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-2022-50650
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:
	include/linux/bpf_verifier.h
	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/4ed5155043c97ac8912bcf67331df87c833fb067
	https://git.kernel.org/stable/c/caa176c0953cdfd5ce500fb517ce1ea924a8bc4c
	https://git.kernel.org/stable/c/aed931fd3b6e28f19cc140ff90aa5046ee2aa4e1
	https://git.kernel.org/stable/c/9d9d00ac29d0ef7ce426964de46fa6b380357d0a

Powered by blists - more mailing lists