The Qualys Threat Research Unit (TRU) has identified two critical race-condition vulnerabilities in core dump handling mechanisms on widely used Linux distributions. These flaws, CVE-2025-5054 (targeting Apport on Ubuntu) and CVE-2025-4598 (targeting systemd-coredump on RHEL, Fedora), can be exploited by local attackers to access memory snapshots (core dumps) of Set User ID (SUID) programs. This unauthorized access can lead to the extraction of sensitive data, including password hashes from processes like unix_chkpwd, encryption keys, and other credentials.
- Vulnerability Details
- CVE-2025-5054: A race condition vulnerability in Apport (Ubuntu’s crash reporting tool, up to version 2.33.0) that allows unauthorized access to core dumps of SUID programs.
- CVE-2025-4598: A race condition vulnerability in systemd-coredump (used by default in RHEL 9/10, Fedora 40/41) that allows unauthorized access to core dumps of SUID programs.
These vulnerabilities allow attackers with local access to precisely time their actions to bypass existing security measures that normally restrict core dump access to root users and secure directories.
- Scope of Impact
- Affected Systems:
- Ubuntu: All versions from 16.04 up to and including 24.04 (via Apport versions up to 2.33.0).
- Red Hat Enterprise Linux (RHEL): Versions 9 and 10 (via systemd-coredump).
- Fedora: Versions 40 and 41 (via systemd-coredump).
- Debian: Largely unaffected by default, as it does not include a core dump handler unless systemd-coredump is explicitly installed. CVE-2025-4598 does not impact any Ubuntu releases.
- Amazon Linux: Has released related advisories.
- Potential Risks:
- Extraction of password hashes (e.g., from /etc/shadow via unix_chkpwd process memory).
- Exposure of encryption keys and other credentials.
- Privilege escalation.
- Lateral movement across networks.
- Serious operational and compliance consequences.
- Proof-of-Concept:Qualys researchers have developed working Proof-of-Concept (PoC) exploits demonstrating the ability to access the unix_chkpwdprocess memory and extract password hashes.
- Vendor Perspectives
- Canonical (Ubuntu): Acknowledges CVE-2025-5054, stating its impact is restricted to the confidentiality of the SUID executable’s memory space and that the PoC hash leak has “limited real-world impact.” They advise caution and testing before broadly deploying mitigations.
- Debian: Systems are not vulnerable to CVE-2025-4598 by default.
- Amazon Linux: Has released advisories.
- Immediate Mitigation:The primary recommended mitigation is to disable core dumps for SUID programs by setting the following kernel parameter: echo 0 > /proc/sys/fs/suid_dumpable
Note: This command applies the setting temporarily. To make it persistent across reboots, add fs.suid_dumpable = 0 to /etc/sysctl.conf (or a file in /etc/sysctl.d/) and then run sysctl -p.
Caution: Disabling SUID core dumps may limit debugging functionality for certain applications and services. Thorough testing in staging environments is crucial before widespread deployment. Qualys has also released mitigation scripts.
- Long-Term Recommendations
- Prioritize patching vulnerable systems once official patches are released by vendors.
- Maintain up-to-date security monitoring.
- Review core dump configurations across all Linux infrastructure
Vulnerability Mitigation Plan
This plan outlines responsibilities for mitigating the identified Linux core dump vulnerabilities.
Phase 1: Immediate Containment & Assessment (Next 24-72 hours)
- All Technical Teams (especially Linux System Administrators, Security Operations):
- Action: Disseminate this security bulletin to all relevant personnel.
- Purpose: Ensure awareness of the vulnerabilities, affected systems, and immediate mitigation steps.
- Linux System Administrators / DevOps Engineers:
- Action: Identify all potentially vulnerable systems within your purview based on the “Scope of Impact” section (Ubuntu 16.04+, RHEL 9/10, Fedora 40/41).
- Ubuntu: Check Apport version (target versions up to 2.33.0).
- RHEL/Fedora: Confirm use of systemd-coredump.
- Debian: Verify if systemd-coredump was manually installed.
- Purpose: Understand the scale of vulnerable assets.
- Action: In non-production/staging environments first, apply the immediate mitigation: echo 0 > /proc/sys/fs/suid_dumpable And make it persistent: add fs.suid_dumpable = 0 to /etc/sysctl.conf (or /etc/sysctl.d/local.conf) and run sysctl -p.
- Purpose: Test the impact of this change on application functionality and debugging capabilities.
- Action: Identify all potentially vulnerable systems within your purview based on the “Scope of Impact” section (Ubuntu 16.04+, RHEL 9/10, Fedora 40/41).
- Application Owners / Development Teams:
- Action: Collaborate with System Administrators to understand which of their applications run on potentially affected systems.
- Action: Assess and report any critical reliance on SUID core dumps for debugging their specific applications.
- Purpose: Identify any potential operational disruptions from the primary mitigation.
- Security Operations Center (SOC) / Incident Response Team:
- Action: Review existing monitoring and detection capabilities for unusual local account activity or unexpected crashes, though direct exploitation of these vulnerabilities might be hard to detect proactively without specific indicators.
- Action: Familiarize themselves with the PoC details (accessing unix_chkpwd memory).
- Purpose: Enhance situational awareness and prepare for potential forensic analysis if exploitation is suspected.
Phase 2: Broader Mitigation & Preparation for Patching (Next 3-7 days)
- Linux System Administrators / DevOps Engineers:
- Action: Based on successful testing in staging, and in coordination with Application Owners, roll out the fs.suid_dumpable = 0 mitigation to production systems, prioritizing the most critical or exposed systems first.
- Action: Document all systems where the mitigation has been applied.
- Action: Monitor vendor notifications (Canonical, Red Hat, Fedora, Amazon) for official patches.
- Purpose: Reduce risk across the production environment while preparing for permanent fixes.
- Security Team (Vulnerability Management):
- Action: Track the deployment of the suid_dumpable mitigation across the environment.
- Action: Act as a central point for vendor patch information and release schedules.
- Action: Begin planning the patch deployment strategy.
- Purpose: Ensure comprehensive mitigation and readiness for patching.
- IT Management / Change Advisory Board (CAB):
- Action: Review and approve emergency changes for the suid_dumpable mitigation deployment if required by organizational policy.
- Action: Be informed about the risks and the status of mitigation efforts.
- Purpose: Provide oversight and support for the mitigation process.
Phase 3: Patch Management & Verification (Ongoing, as patches become available)
- Linux System Administrators / DevOps Engineers:
- Action: Once official patches are released by vendors, test them in non-production environments.
- Action: Deploy patches to production systems according to the organization’s patch management policy, prioritizing critical systems.
- Action: After patching, verify that the vulnerabilities are remediated. Consider if fs.suid_dumpable can be reverted to 1 (default) on a system-by-system basis if full debugging capabilities are needed and the patch adequately covers the risk. This decision should be risk-based.
- Purpose: Permanently fix the vulnerabilities.
- Security Team (Vulnerability Management):
- Action: Validate patch deployment and vulnerability remediation using scanning tools or manual verification where appropriate.
- Action: Update vulnerability tracking systems.
- Purpose: Confirm risk reduction.
- All Teams:
- Action: Conduct a post-mortem or lessons-learned session after the patching cycle is complete to improve future vulnerability response.
- Purpose: Continual process improvement.

