CVE-2025-71078 Linux CVE debrief

Who should care

Linux system administrators, Linux kernel developers, and security teams responsible for maintaining Linux-based systems should be aware of this vulnerability and take steps to mitigate it.

Technical summary

The Linux kernel's software SLB preload cache, which mirrors entries loaded into the hardware SLB buffer on systems using the hash MMU, can become inconsistent with the hardware SLB when the kernel skips switch_mmu_context() in switch_mm_irqs_off(). This inconsistency can lead to stale SLB entries being retained in the hardware SLB, causing a multihit error when the kernel attempts to reload those entries. Affected configurations include Linux kernel versions from 4.20.1 to 5.10.248, 5.11 to 5.15.198, 5.16 to 6.1.160, 6.2 to 6.6.120, 6.7 to 6.12.64, and 6.13 to 6.18.4. The vulnerability requires immediate attention, and Linux systems using the hash MMU are affected. An attacker with local access could potentially exploit this vulnerability to cause a denial-of-service or execute arbitrary code. To mitigate this vulnerability, it is recommended to apply patches provided by Linux kernel maintainers to address the SLB multihit issue, ensure Linux systems are updated with the latest kernel versions, monitor system logs for potential SLB multihit errors, and implement compensating controls to detect and prevent exploitation attempts. Additionally, Linux system administrators should review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance, and plan vendor-supported updates or mitigations through normal change control where exposure is confirmed. Compensating controls for exposed systems should be reviewed while remediation is scheduled and verified. Relevant monitoring, detection, and logs for exposed assets should be checked, and exceptions, retest remediated assets, and close the item only after evidence is documented. Asset inventory and source tracking should also be considered to ensure comprehensive mitigation. Rollback/change windows should be planned to minimize potential impact on system availability. Monitoring and detection capabilities should be implemented to identify potential exploitation attempts. By taking these steps, Linux system administrators can help prevent exploitation of this vulnerability and reduce the risk of a denial-of-service or arbitrary code execution. It is essential to prioritize 7

Defensive priority

This SLB multihit issue during SLB preload in the Linux kernel requires immediate attention. Linux systems using the hash MMU are affected, and an attacker with local access could potentially exploit this vulnerability to cause a denial-of-service or execute arbitrary code.

Recommended defensive actions

• Apply patches provided by Linux kernel maintainers to address the SLB multihit issue
• Ensure Linux systems are updated with the latest kernel versions
• Monitor system logs for potential SLB multihit errors
• Implement compensating controls to detect and prevent exploitation attempts
• Review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance
• Plan vendor-supported updates or mitigations through normal change control where exposure is confirmed
• Track exceptions, retest remediated assets, and close the item only after evidence is documented

Evidence notes

The Linux kernel's software SLB preload cache, which mirrors entries loaded into the hardware SLB buffer on systems using the hash MMU, can become inconsistent with the hardware SLB when the kernel skips switch_mmu_context() in switch_mm_irqs_off(). This inconsistency can lead to stale SLB entries being retained in the hardware SLB, causing a multihit error when the kernel attempts to reload those entries. Affected configurations include Linux kernel versions from 4.20.1 to 5.10.248, 5.11 to 5.15.198, 5.16 to 6.1.160, 6.2 to 6.6.120, 6.7 to 6.12.64, and 6.13 to 6.18.4.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.