CVE-2023-52828
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
21/05/2024
Last modified:
26/09/2025
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
bpf: Detect IP == ksym.end as part of BPF program<br />
<br />
Now that bpf_throw kfunc is the first such call instruction that has<br />
noreturn semantics within the verifier, this also kicks in dead code<br />
elimination in unprecedented ways. For one, any instruction following<br />
a bpf_throw call will never be marked as seen. Moreover, if a callchain<br />
ends up throwing, any instructions after the call instruction to the<br />
eventually throwing subprog in callers will also never be marked as<br />
seen.<br />
<br />
The tempting way to fix this would be to emit extra &#39;int3&#39; instructions<br />
which bump the jited_len of a program, and ensure that during runtime<br />
when a program throws, we can discover its boundaries even if the call<br />
instruction to bpf_throw (or to subprogs that always throw) is emitted<br />
as the final instruction in the program.<br />
<br />
An example of such a program would be this:<br />
<br />
do_something():<br />
...<br />
r0 = 0<br />
exit<br />
<br />
foo():<br />
r1 = 0<br />
call bpf_throw<br />
r0 = 0<br />
exit<br />
<br />
bar(cond):<br />
if r1 != 0 goto pc+2<br />
call do_something<br />
exit<br />
call foo<br />
r0 = 0 // Never seen by verifier<br />
exit //<br />
<br />
main(ctx):<br />
r1 = ...<br />
call bar<br />
r0 = 0<br />
exit<br />
<br />
Here, if we do end up throwing, the stacktrace would be the following:<br />
<br />
bpf_throw<br />
foo<br />
bar<br />
main<br />
<br />
In bar, the final instruction emitted will be the call to foo, as such,<br />
the return address will be the subsequent instruction (which the JIT<br />
emits as int3 on x86). This will end up lying outside the jited_len of<br />
the program, thus, when unwinding, we will fail to discover the return<br />
address as belonging to any program and end up in a panic due to the<br />
unreliable stack unwinding of BPF programs that we never expect.<br />
<br />
To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as<br />
part of the BPF program, so that is_bpf_text_address returns true when<br />
such a case occurs, and we are able to unwind reliably when the final<br />
instruction ends up being a call instruction.
Impact
Base Score 3.x
5.50
Severity 3.x
MEDIUM
Vulnerable products and versions
| CPE | From | Up to |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 5.10.202 (excluding) | |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 5.11 (including) | 5.15.140 (excluding) |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 5.16 (including) | 6.1.64 (excluding) |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.2 (including) | 6.5.13 (excluding) |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.6 (including) | 6.6.3 (excluding) |
To consult the complete list of CPE names with products and versions, see this page
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5
- https://git.kernel.org/stable/c/6058e4829696412457729a00734969acc6fd1d18
- https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21
- https://git.kernel.org/stable/c/821a7e4143af115b840ec199eb179537e18af922
- https://git.kernel.org/stable/c/aa42a7cb92647786719fe9608685da345883878f
- https://git.kernel.org/stable/c/cf353904a82873e952633fcac4385c2fcd3a46e1
- https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5
- https://git.kernel.org/stable/c/6058e4829696412457729a00734969acc6fd1d18
- https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21
- https://git.kernel.org/stable/c/821a7e4143af115b840ec199eb179537e18af922
- https://git.kernel.org/stable/c/aa42a7cb92647786719fe9608685da345883878f
- https://git.kernel.org/stable/c/cf353904a82873e952633fcac4385c2fcd3a46e1



