CVE-2025-38433

In the Linux kernel, the following vulnerability has been resolved: riscv: fix runtime constant support for nommu kernels the `__runtime_fixup_32` function does not handle the case where `val` is zero correctly (as might occur when patching a nommu kernel and referring to a physical address below the 4GiB boundary whose upper 32 bits are all zero) because nothing in the existing logic prevents the code from taking the `else` branch of both nop-checks and emitting two `nop` instructions. This leaves random garbage in the register that is supposed to receive the upper 32 bits of the pointer instead of zero that when combined with the value for the lower 32 bits yields an invalid pointer and causes a kernel panic when that pointer is eventually accessed. The author clearly considered the fact that if the `lui` is converted into a `nop` that the second instruction needs to be adjusted to become an `li` instead of an `addi`, hence introducing the `addi_insn_mask` variable, but didn't follow that logic through fully to the case where the `else` branch executes. To fix it just adjust the logic to ensure that the second `else` branch is not taken if the first instruction will be patched to a `nop`.
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc3:*:*:*:*:*:*

History

19 Nov 2025, 18:08

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: se corrige el soporte de constantes de tiempo de ejecución para kernels nommu la función `__runtime_fixup_32` no maneja el caso donde `val` es cero correctamente (como podría ocurrir al parchar un kernel nommu y hacer referencia a una dirección física por debajo del límite de 4GiB cuyos 32 bits superiores son todos cero) porque nada en la lógica existente evita que el código tome la rama `else` de ambos nop-checks y emita dos instrucciones `nop`. Esto deja basura aleatoria en el registro que se supone que recibe los 32 bits superiores del puntero en lugar de cero que, cuando se combina con el valor de los 32 bits inferiores, produce un puntero no válido y causa un pánico del kernel cuando finalmente se accede a ese puntero. El autor consideró claramente que si la instrucción `lui` se convierte en `nop`, la segunda instrucción debe ajustarse para que se convierta en `li` en lugar de `addi`, introduciendo así la variable `addi_insn_mask`. Sin embargo, no siguió esta lógica completamente hasta el caso en que se ejecuta la rama `else`. Para solucionarlo, simplemente ajuste la lógica para garantizar que la segunda rama `else` no se ejecute si la primera instrucción se convierte en `nop`.
References () https://git.kernel.org/stable/c/0a24b00dcde83934a3cc13e4c6b775522903496b - () https://git.kernel.org/stable/c/0a24b00dcde83934a3cc13e4c6b775522903496b - Patch
References () https://git.kernel.org/stable/c/8d90d9872edae7e78c3a12b98e239bfaa66f3639 - () https://git.kernel.org/stable/c/8d90d9872edae7e78c3a12b98e239bfaa66f3639 - Patch
CWE CWE-476
First Time Linux
Linux linux Kernel
CPE cpe:2.3:o:linux:linux_kernel:6.16:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.16:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5

25 Jul 2025, 15:15

Type Values Removed Values Added
New CVE

Information

Published : 2025-07-25 15:15

Updated : 2025-11-19 18:08


NVD link : CVE-2025-38433

Mitre link : CVE-2025-38433

CVE.ORG link : CVE-2025-38433


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-476

NULL Pointer Dereference