bpf: Don't predict JMP32 pointer vs zero comparisons
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.6.160, 6.12.111, 6.18.53, 7.2.7
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In the Linux kernel, the following vulnerability has been resolved: bpf: Don't predict JMP32 pointer vs zero comparisons Consider the following program: 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; 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 ...'.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From cac616db39c207dc63465a4e05c6ce0e60b2cce4 · fixed in 6e1544986536734166176c3add504add23bcbd15; From cac616db39c207dc63465a4e05c6ce0e60b2cce4 · fixed in d16f0eafcaa62e677a2b5b0dabc1f8d31dfe3d4d; From cac616db39c207dc63465a4e05c6ce0e60b2cce4 · fixed in e2ae33247e8b2dbe9d116d3e61cadf6d548339c6; From cac616db39c207dc63465a4e05c6ce0e60b2cce4 · fixed in a4d7f94c1ca914469ced665ec2f98be669aef462; From cac616db39c207dc63465a4e05c6ce0e60b2cce4 · fixed in e51179a4e09846f8fd0f26a05068520de2b301bf
- Linux Linux
5.8
- KernelLinux
From 5.8.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.111; From 6.13.0 · fixed in 6.18.53; From 6.19.0 · fixed in 7.2.7