In the Linux kernel, the following vulnerability has been resolved:
bpf: Don't predict JMP32 pointer vs zero comparisons
Consider the following program:
<pre>
r1 = map_value; /* low 32 bits are zero at runtime */
r6 = 0xdead000000000000;
if w1 != 0 goto l1;
l0: r1 += r6;
r2 = *(u64 *)(r1 + 0);
exit;
l1: r6 = 0;
goto l0;
</pre>
At the moment is_branch_taken() reports the jump as always taken,
because it does not distinguish between BPF_JMP and BPF_JMP32
comparisons when processing 'if w1 != 0 ...'.
CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7
AV:L - The attacker must load a BPF program locally with bpf(BPF_PROG_LOAD). bpf_check() -> check_cond_jmp_op() -> is_branch_taken() then mispredicts a JMP32 'if wX != 0' on a pointer register. No network peer supplies any of the input.
AC:H - The fall-through only diverges at runtime when the pointer's low 32 bits happen to be zero. An unprivileged attacker cannot read kernel addresses, so they cannot choose that alignment. That route also needs the non-default setting unprivileged_bpf_disabled=0 and a way past the verifier's unprivileged mitigations.
PR:L - For JMP32 compares of a pointer against immediate 0, is_branch_taken() runs before the 'pointer comparison prohibited' check, so unprivileged socket-filter programs reach it when kernel.unprivileged_bpf_disabled=0. That setting is non-default on current kernels but was upstream's default on older affected kernels. Otherwise CAP_BPF in init_user_ns is required.
UI:N - The attacker writes, loads and runs the BPF program themselves, for example by attaching a socket filter to their own socket and sending traffic. No other user has to act.
S:U - The result is a kernel privilege escalation inside the same kernel security authority. The bug does not cross a VM or hypervisor boundary.
C:H - Unverified code on the path the verifier thought unreachable can add an arbitrary scalar to a pointer the verifier believes is in bounds, for example the fix commit's r1 += r6 with r6=0xdead000000000000. The following load then reads arbitrary kernel memory.
I:H - The same out-of-bounds pointer can be used as the target of a store, so the bypass gives an arbitrary kernel write and a path to code execution or credential overwrite.
A:H - Dereferencing the wild pointer on the mispredicted path, such as 0xdead000000000000 in the commit's reproducer, oopses or panics the kernel.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
High |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The attacker must load a BPF program locally with bpf(BPF_PROG_LOAD). bpf_check() -> check_cond_jmp_op() -> is_branch_taken() then mispredicts a JMP32 'if wX != 0' on a pointer register. No network peer supplies any of the input.
AC:H - The fall-through only diverges at runtime when the pointer's low 32 bits happen to be zero. An unprivileged attacker cannot read kernel addresses, so they cannot choose that alignment. That route also needs the non-default setting unprivileged_bpf_disabled=0 and a way past the verifier's unprivileged mitigations.
PR:L - For JMP32 compares of a pointer against immediate 0, is_branch_taken() runs before the 'pointer comparison prohibited' check, so unprivileged socket-filter programs reach it when kernel.unprivileged_bpf_disabled=0. That setting is non-default on current kernels but was upstream's default on older affected kernels. Otherwise CAP_BPF in init_user_ns is required.
UI:N - The attacker writes, loads and runs the BPF program themselves, for example by attaching a socket filter to their own socket and sending traffic. No other user has to act.
S:U - The result is a kernel privilege escalation inside the same kernel security authority. The bug does not cross a VM or hypervisor boundary.
C:H - Unverified code on the path the verifier thought unreachable can add an arbitrary scalar to a pointer the verifier believes is in bounds, for example the fix commit's r1 += r6 with r6=0xdead000000000000. The following load then reads arbitrary kernel memory.
I:H - The same out-of-bounds pointer can be used as the target of a store, so the bypass gives an arbitrary kernel write and a path to code execution or credential overwrite.
A:H - Dereferencing the wild pointer on the mispredicted path, such as 0xdead000000000000 in the commit's reproducer, oopses or panics the kernel.
CVSS 3.1