cbcvebase.
CVE-2025-39748
published 2025-09-11

CVE-2025-39748: In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a…

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

Affected

57 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.16.3-1 (forky)linux 6.16.3-1 (forky)
linuxlinux
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < 22191359f8454b0be082c3b126f86bcbea0f131822191359f8454b0be082c3b126f86bcbea0f1318
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < c29dd8336236a4deb75596b52d2dd16ccc4a380dc29dd8336236a4deb75596b52d2dd16ccc4a380d
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < 591c788d16046edb0220800bf1819554af5853ce591c788d16046edb0220800bf1819554af5853ce
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < 0643aa2468192a4d81326e8e76543854870b1ee20643aa2468192a4d81326e8e76543854870b1ee2
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < f01e06930444cab289a8783017af9b64255bd103f01e06930444cab289a8783017af9b64255bd103
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < 2fd0c26bacd90ef26522bd3169000a4715bf151f2fd0c26bacd90ef26522bd3169000a4715bf151f
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < 80a6b11862a7cfdf691e8f9faee89cfea219f09880a6b11862a7cfdf691e8f9faee89cfea219f098
linuxlinux>= 960ea056561a08e2b837b2f02d22c53226414a84 < 6279846b9b2532e1b04559ef8bd0dec049f293836279846b9b2532e1b04559ef8bd0dec049f29383
linuxlinux_kernel< 6.12.436.12.43
linuxlinux_kernel>= 0 < 6.12.43-16.12.43-1
linuxlinux_kernel>= 0 < 6.16.3-16.16.3-1
linuxlinux_kernel>= 0 < 6.8.0-100.1006.8.0-100.100
linuxlinux_kernel>= 6.13 < 6.15.116.15.11
linuxlinux_kernel>= 6.16 < 6.16.26.16.2
msrcazl3_kernel_6.6.104.2-4_on_azure_linux_3.0
msrcazl3_kernel_6.6.112.1-2_on_azure_linux_3.0
msrcazl3_kernel_6.6.117.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-3_on_azure_linux_3.0
msrcazl3_kernel_6.6.121.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.126.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.96.2-2_on_azure_linux_3.0
msrccbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_ubuntu7.1HIGH
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.