CVE-2025-39763 in Linux
Summary
by MITRE • 09/11/2025
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered
If a synchronous error is detected as a result of user-space process triggering a 2-bit uncorrected error, the CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64. The kernel will queue a memory_failure() work which poisons the related page, unmaps the page, and then sends a SIGBUS to the process, so that a system wide panic can be avoided.
However, no memory_failure() work will be queued when abnormal synchronous errors occur. These errors can include situations like invalid PA, unexpected severity, no memory failure config support, invalid GUID section, etc. In such a case, the user-space process will trigger SEA again. This loop can potentially exceed the platform firmware threshold or even trigger a kernel hard lockup, leading to a system reboot.
Fix it by performing a force kill if no memory_failure() work is queued for synchronous errors.
[ rjw: Changelog edits ]
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability described in CVE-2025-39763 represents a critical flaw in the Linux kernel's Advanced Configuration and Power Interface (ACPI) subsystem, specifically within the APEI (ACPI Platform Error Interface) error handling mechanisms. This issue manifests when the kernel encounters synchronous memory errors that occur during user-space process execution, creating a dangerous loop that can lead to system instability and potential denial of service conditions. The vulnerability stems from the kernel's inconsistent handling of memory error recovery scenarios, particularly when synchronous errors cannot be properly processed through the standard memory_failure() work queue mechanism.
The technical root cause involves the kernel's handling of synchronous external aborts (SEA) on arm64 architectures when user-space processes trigger 2-bit uncorrected memory errors. Under normal circumstances, when such errors occur, the kernel properly executes the memory_failure() work queue which poisons the affected page, unmmaps it, and sends a SIGBUS signal to the offending process to prevent system-wide panic. However, the vulnerability emerges when abnormal synchronous errors occur that do not qualify for memory_failure() work queue processing. These abnormal conditions include invalid physical addresses, unexpected error severity levels, lack of memory failure configuration support, or invalid GUID section formats. When these specific error conditions are encountered, the kernel fails to queue the memory_failure() work and instead allows the user-space process to trigger the synchronous error exception repeatedly.
The operational impact of this vulnerability is severe and potentially catastrophic for system stability. The repeated triggering of synchronous external aborts creates a feedback loop that can quickly exceed platform firmware thresholds, leading to system lockups and forced reboots. This behavior effectively creates a denial of service condition where legitimate user-space processes can be used as attack vectors to destabilize the entire system. The vulnerability is particularly dangerous because it operates at the kernel level and can be exploited through user-space processes, making it difficult to detect and prevent. The potential for triggering kernel hard lockups means that even a single malicious or malformed process could bring down an entire system, making this a high-severity issue for any production environment relying on Linux kernel memory error handling.
The fix implemented for CVE-2025-39763 addresses this by introducing a force kill mechanism when no memory_failure() work is queued for synchronous errors. This approach ensures that when the kernel cannot properly handle a synchronous memory error through normal recovery mechanisms, it will terminate the offending process rather than allowing the error loop to continue. This solution aligns with the principle of least privilege and system stability, preventing malicious or faulty processes from causing system-wide failures. The mitigation strategy follows established security practices by ensuring that error conditions are properly terminated rather than allowed to escalate into more serious system failures. This fix directly addresses the CWE-704 weakness related to improper error handling and aligns with ATT&CK technique T1499.004 for network denial of service, as it prevents the escalation of memory errors into system-wide instability. The solution maintains the kernel's ability to handle normal error conditions while preventing the dangerous loop that could lead to system lockups and hard reboots.