bpf: Don't resurrect a scalar id dropped by collect_linked_regs()
- 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 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 resurrect a scalar id dropped by collect_linked_regs() check_cond_jmp_op() copies the compared registers into env->{false,true}_reg{1,2} before collect_linked_regs() runs and copies those snapshots back into both branch states afterwards. collect_linked_regs() records at most LINKED_REGS_MAX members of a linked registers group in the jump history and calls clear_scalar_id() for every member that does not fit. The compared register is not exempt from that. As a consequence, sync_linked_regs() might adjust ranges for more registers than bpf_bt_sync_linked_regs() can propagate precision to. Collect the linked registers before the snapshots are taken instead. This might lead to some unnecessary clear_scalar_id's, but from previous testing situations with many linked registers are extremely rare.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From ec1d77cb0ee98249142dcd0376d76e7a48ba0b31 · fixed in e821ff19b8ef08255ff8d8234774ed814637e9bf; From ec1d77cb0ee98249142dcd0376d76e7a48ba0b31 · fixed in 73a98f96811e2cb0f4210b1caa8cb322f92f2a2b
- Linux Linux
7.1
- KernelLinux
From 7.1.0 · fixed in 7.2.7