Cloudanix VulnDB

CVE-2025-37991

None

CVSS

—

EPSS

0.2%

Published

May 20, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

On certain older Linux systems running on parisc hardware, math errors could cause programs to crash with a second error inside their own error handler, leading to unexpected application failures.

Exploitation
Other
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

On parisc, a SIGFPE handler triggers a second SIGFPE because glibc lazy-binding FP stores set the T bit in the FP status register; the kernel does not clear this bit before returning to userspace, so the handler itself faults.

Why it matters to the business

Applications performing floating-point operations on affected parisc systems can crash with repeated signals, causing service outages or unexpected process termination on long-supported Ubuntu releases.

How an attack unfolds

An attacker or local process triggers a floating-point exception (e.g., overflow) while a signal handler is installed; glibc's double-word FP store inside the handler immediately re-triggers the exception because the T bit remains set, resulting in recursive SIGFPE and process death. No named threat actors are associated with this specific issue.

How to fix it

Upgrade to a fixed kernel package for each affected Ubuntu release: linux 3.11.0-12.19 (14.04), 4.4.0-2.16 (16.04), 4.13.0-16.19 (18.04), 5.4.0-9.12 (20.04) and the corresponding linux-aws, linux-azure, linux-gcp, linux-hwe, linux-kvm, linux-oracle variants listed in the fixed_versions field.

How to confirm the fix worked

Verify the running kernel version matches or exceeds the fixed package for the distribution release; confirm the parisc-specific FP status register T-bit clearing logic is present in the signal-return path.

Typical attack path

  1. Install a SIGFPE handler using SA_SIGINFO
  2. Enable floating-point exceptions via feenableexcept
  3. Execute an operation that produces FE_OVERFLOW
  4. Kernel delivers first SIGFPE; glibc FP store in handler causes second trap
  5. Process killed by repeated SIGFPE

How to detect it

Search kernel and application logs for repeated SIGFPE deliveries to the same process in rapid succession; examine strace output showing consecutive --- SIGFPE --- entries followed by killed by SIGFPE; no public exploitation artifacts are known.

What your security team should do

  • Prioritize patching parisc systems running the listed Ubuntu LTS kernels before the next maintenance window
  • Rebuild any custom kernels with the upstream fix that clears the FP T bit on signal return
  • Monitor EPSS trend (currently low) and re-evaluate if new exploit code appears

The record

In the Linux kernel, the following vulnerability has been resolved: parisc: Fix double SIGFPE crash Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:11 linux-6.1 0 6.1.140-1~deb11u1
Debian:12 linux 0 6.1.140-1
Debian:13 linux 0 No fix
Debian:13 linux 0 6.12.29-1
Debian:14 linux 0 6.12.29-1
Linux Kernel 0 5.4.294
Linux Kernel 2.6.12 5.4.294
Mageia:9 dwarves 0 1.30-1.mga9
Mageia:9 kernel 0 6.6.93-1.mga9
Mageia:9 kernel-firmware 0 20250509-1.mga9
Mageia:9 kernel-firmware-nonfree 0 20250509-1.mga9.nonfree
Mageia:9 kernel-linus 0 6.6.93-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.8-3.mga9
Mageia:9 kmod-xtables-addons 0 3.24-80.mga9
Mageia:9 libtraceevent 0 1.8.4-1.mga9
Mageia:9 libtracefs 0 1.8.2-1.mga9
Mageia:9 radeon-firmware 0 20250509-1.mga9.nonfree
Mageia:9 wireless-regdb 0 20250220-1.mga9

Related vulnerabilities