CVE-2025-39748

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Forget ranges when refining tnum after JSET<br /> <br /> Syzbot reported a kernel warning due to a range invariant violation on<br /> the following BPF program.<br /> <br /> 0: call bpf_get_netns_cookie<br /> 1: if r0 == 0 goto <br /> 2: if r0 &amp; Oxffffffff goto <br /> <br /> The issue is on the path where we fall through both jumps.<br /> <br /> That path is unreachable at runtime: after insn 1, we know r0 != 0, but<br /> with the sign extension on the jset, we would only fallthrough insn 2<br /> if r0 == 0. Unfortunately, is_branch_taken() isn&amp;#39;t currently able to<br /> figure this out, so the verifier walks all branches. The verifier then<br /> refines the register bounds using the second condition and we end<br /> up with inconsistent bounds on this unreachable path:<br /> <br /> 1: if r0 == 0 goto <br /> r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff)<br /> 2: if r0 &amp; 0xffffffff goto <br /> r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0)<br /> r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0)<br /> <br /> Improving the range refinement for JSET to cover all cases is tricky. We<br /> also don&amp;#39;t expect many users to rely on JSET given LLVM doesn&amp;#39;t generate<br /> those instructions. So instead of improving the range refinement for<br /> JSETs, Eduard suggested we forget the ranges whenever we&amp;#39;re narrowing<br /> tnums after a JSET. This patch implements that approach.