CVE-2026-98042: bpf: Don't resurrect a scalar id dropped by collect_linked_regs()
In the Linux kernel, the following vulnerability has been resolved:
bpf: Don't resurrect a scalar id dropped by collectlinkedregs()
checkcondjmpop() copies the compared registers into env->{false,true}reg{1,2} before collectlinkedregs() runs and copies those snapshots back into both branch states afterwards.
collectlinkedregs() records at most LINKEDREGSMAX members of a linked registers group in the jump history and calls clearscalarid() for every member that does not fit. The compared register is not exempt from that.
As a consequence, synclinkedregs() might adjust ranges for more registers than bpfbtsynclinkedregs() can propagate precision to.
Collect the linked registers before the snapshots are taken instead. This might lead to some unnecessary clearscalarid's, but from previous testing situations with many linked registers are extremely rare.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The issue requires a BPF verifier path involving conditional jumps and a linked-register group with more members than LINKED_REGS_MAX. The description notes that situations with many linked registers are extremely rare.
What is the practical effect of the flawed verifier state handling?
A scalar ID cleared for a linked register that does not fit in jump history can be restored from branch-state register snapshots. This can leave range adjustments affecting more registers than precision propagation can cover.
Is there an indicated workaround if the kernel update cannot be applied immediately?
No workaround or mitigation is provided in the available data. The described resolution changes the verifier flow so linked registers are collected before compared-register snapshots are taken.