CVE-2025-39763

What it actually does

The kernel omits queuing memory_failure() work for abnormal synchronous errors (invalid PA, unexpected severity, missing config, invalid GUID), allowing repeated SEA exceptions that can exceed firmware thresholds or trigger hard lockups and reboot.

Why it matters to the business

Systems may suffer unexpected reboots or prolonged unavailability when user-space processes encounter certain hardware memory errors, increasing downtime risk in production Linux environments with high prevalence of kernel deployments.

How an attack unfolds

An attacker or faulty process triggers a 2-bit uncorrected memory error that produces an abnormal synchronous exception; because no memory_failure() work is queued the kernel does not send SIGBUS, the process repeats the access, the exception loop escalates until firmware or watchdog forces a reboot.

How to fix it

Update the Linux kernel to commit 2fbc85da9ac9386bd89fcc94e0aadaea19d47784 or later stable releases containing the force-kill change for synchronous errors without queued memory_failure() work.

How to confirm the fix worked

Verify the running kernel contains commit 2fbc85da9ac9386bd89fcc94e0aadaea19d47784; test by injecting abnormal synchronous memory errors and confirming SIGBUS is delivered instead of repeated exceptions.

Typical attack path

1. Trigger synchronous uncorrected memory error from user-space via crafted access or hardware fault
2. Kernel detects abnormal error conditions and skips memory_failure() queuing
3. Process receives no SIGBUS and re-executes the faulting instruction
4. Repeated exceptions accumulate until platform threshold or hard lockup occurs
5. System reboots or becomes unresponsive

How to detect it

Inspect kernel logs for repeated Synchronous External Abort or memory error exceptions without accompanying memory_failure() or SIGBUS messages; correlate with process termination patterns or watchdog-induced reboots on systems running vulnerable kernels.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all affected systems before the CISA-style deadlines if adopted internally
• Enable and monitor hardware error reporting (APEI, EDAC) to detect recurring memory faults early
• Review container and VM workloads for memory-error-prone access patterns that could trigger the loop