Get a Demo

Let's Patch It!

Book a short call with one our specialists, we'll walk you through how Endor Patches work, and ask you a few questions about your environment (like your primary programming languages and repository management). We'll also send you an email right after you fill out the form, feel free to reply with any questions you have in advance!

CVE

DEBIAN-CVE-2025-71078

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s/slb: Fix SLB multihit issue during SLB preload On systems using the hash MMU, there is a software SLB preload cache th...
Back to all
CVE

DEBIAN-CVE-2025-71078

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s/slb: Fix SLB multihit issue during SLB preload On systems using the hash MMU, there is a software SLB preload cache th...

In the Linux kernel, the following vulnerability has been resolved:  powerpc/64s/slb: Fix SLB multihit issue during SLB preload  On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry.  To optimize performance, the kernel skips switchmmucontext() in switchmmirqsoff() when the prev and next mmstruct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache.  If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switchmmucontext(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error.  The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch.  CPU 0                                   CPU 1 -----                                    ----- Process P exec                                    swapper/1  loadelfbinary   beginnewexc     activatemm      switchmmirqsoff       switchmmucontext        switchslb        /          This invalidates all          the entries in the HW          and setup the new HW          SLB entries as per the          preload cache.         / contextswitch schedmigratetask migrates process P to cpu-1  Process swapper/0                       context switch (to process P) (uses mmstruct of Process P)           switchmmirqsoff()                                          switchslb                                            loadslb++                                             /                                              loadslb becomes 0 here                                              and we evict an entry from                                              the preload cache with                                              preloadage(). We still                                              keep HW SLB and preload                                              cache in sync, that is                                              because all HW SLB entries                                              anyways gets evicted in                                              switchslb during SLBIA.                                              We then only add those                                              entries back in HW SLB,                                              which are currently                                              present in preloadcache                                              (after eviction).                                             /                                         loadelfbinary continues...                                          setupnewexec()                                           slbsetupnewexec()                                          schedswitch event                                         schedmigratetask migrates                                         process P to cpu-0  contextswitch from swapper/0 to Process P  switchmmirqsoff()   /     Since both prev and next mm struct are same we don't call     switchmmucontext(). This will cause the HW SLB and SW preload     cache to go out of sync in preloadnewslbcontext. Because there     was an SLB entry which was evicted from both HW and preload cache     on cpu-1. Now later in preloadnewslbcontext(), when we will try     to add the same preload entry again, we will add this to the SW     preload cache and then will add it to the HW SLB. Since on cpu-0     this entry was never invalidated, hence adding this entry to the HW     SLB will cause a SLB multi-hit error.    / loadelfbinary cont ---truncated---

Package Versions Affected

Package Version
patch Availability
No items found.

Automatically patch vulnerabilities without upgrading

Fix Without Upgrading
Detect compatible fix
Apply safe remediation
Fix with a single pull request

CVSS Version

Severity
Base Score
CVSS Version
Score Vector
C
H
U
-
C
H
U
0
-
3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
C
H
U
-

Related Resources

No items found.

References

https://security-tracker.debian.org/tracker/CVE-2025-71078

Severity

7.8

CVSS Score
0
10

Basic Information

Ecosystem
Base CVSS
7.8
EPSS Probability
0%
EPSS Percentile
0%
Introduced Version
0
Fix Available
6.1.162-1,6.12.69-1,6.18.5-1,6.1.162-1~deb11u1

Fix Critical Vulnerabilities Instantly

Secure your app without upgrading.
Fix Without Upgrading