Linux kernel x86/mm: missing SMP barrier in switch_mm lets a context switch skip a required TLB flush

CVSS 7.8CVE-2025-40174Kernel, userspace & hypervisorcurated

Impact

There was no guaranteed smp_mb() between the loaded_mm store and the tlb_gen load in switch_mm_irqs_off(), so the ordering against flush_tlb_mm_range() could be lost and a CPU could fail to observe a recent TLB generation bump. The result is stale TLB entries: a core keeps translating through a mapping the kernel believes it has torn down, which is silent memory corruption and a potential read of pages that have already been reused by another process. On a GPU node this is worse than on a general server because the boxes are large, highly parallel and multi-tenant - many cores context-switching between containers is exactly the condition that makes the race observable, and the failure mode gives no clean signal before data is wrong.

Who can reach it

Local: any workload scheduled on the host that triggers concurrent munmap/TLB-flush and context switches on other cores. No special privilege is named. This is an SMP timing race, not a directly steerable primitive, so treat it as a correctness and integrity risk rather than a reliable exploit path.

What to do

Take the stable kernel carrying the barrier fix (the two commits in the record) and reboot each node. There is no tunable or module-level mitigation - this is core x86 memory management. Fold it into the next fleet-wide kernel roll rather than an emergency window unless you are already chasing unexplained memory corruption.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-40174 https://git.kernel.org/stable/c/0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb https://git.kernel.org/stable/c/83b0177a6c4889b3a6e865da5e21b2c9d97d0551

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.