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 range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto <exit> 2: if r0 & Oxffffffff goto <exit> 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 <exit> r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto <exit> 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.
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

History

19 Oct 2026, 21:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: bpf: Olvidar rangos al refinar tnum después de JSET Syzbot informó una advertencia del kernel debido a una violación de invariante de rango en el siguiente programa BPF. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto <exit> 2: if r0 & Oxffffffff goto <exit> El problema está en la ruta donde caemos a través de ambos saltos. Esa ruta es inalcanzable en tiempo de ejecución: después de la instrucción 1, sabemos que r0 != 0, pero con la extensión de signo en el jset, solo caeríamos a través de la instrucción 2 si r0 == 0. Desafortunadamente, is_branch_taken() no es capaz actualmente de determinar esto, por lo que el verificador recorre todas las ramas. El verificador luego refina los límites del registro usando la segunda condición y terminamos con límites inconsistentes en esta ruta inalcanzable: 1: if r0 == 0 goto <exit> r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto <exit> r0 antes de reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 después de reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Mejorar el refinamiento de rango para JSET para cubrir todos los casos es complicado. Tampoco esperamos que muchos usuarios dependan de JSET dado que LLVM no genera esas instrucciones. Así que, en lugar de mejorar el refinamiento de rango para los JSET, Eduard sugirió que olvidemos los rangos cada vez que estemos estrechando tnums después de un JSET. Este parche implementa ese enfoque.

15 Oct 2026, 02:17

Type Values Removed Values Added
References
  • () https://cert-portal.siemens.com/productcert/html/ssa-457936.html -
  • () https://cert-portal.siemens.com/productcert/html/ssa-784472.html -

Information

Published : 2025-09-11 17:15

Updated : 2026-11-10 13:17


NVD link : CVE-2025-39748

Mitre link : CVE-2025-39748

CVE.ORG link : CVE-2025-39748


JSON object : View

Products Affected

linux

  • linux_kernel