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 &amp;#39;int3&amp;#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.

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)