{"api_version":"1","generated_at":"2026-10-24T13:18:35+00:00","cve":"CVE-2025-40174","urls":{"html":"https://cve.report/CVE-2025-40174","api":"https://cve.report/api/cve/CVE-2025-40174.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2025-40174","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2025-40174"},"summary":{"title":"x86/mm: Fix SMP ordering in switch_mm_irqs_off()","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Fix SMP ordering in switch_mm_irqs_off()\n\nStephen noted that it is possible to not have an smp_mb() between\nthe loaded_mm store and the tlb_gen load in switch_mm(), meaning the\nordering against flush_tlb_mm_range() goes out the window, and it\nbecomes possible for switch_mm() to not observe a recent tlb_gen\nupdate and fail to flush the TLBs.\n\n[ dhansen: merge conflict fixed by Ingo ]","state":"PUBLISHED","assigner":"Linux","published_at":"2025-11-12 11:15:47","updated_at":"2026-10-19 21:10:00"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"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"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/83b0177a6c4889b3a6e865da5e21b2c9d97d0551","name":"https://git.kernel.org/stable/c/83b0177a6c4889b3a6e865da5e21b2c9d97d0551","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb","name":"https://git.kernel.org/stable/c/0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-40174","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40174","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 209954cbc7d0ce1a190fc725d20ce303d74d2680 0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 209954cbc7d0ce1a190fc725d20ce303d74d2680 83b0177a6c4889b3a6e865da5e21b2c9d97d0551 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.14","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.14 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.17.5 6.17.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2025","cve_id":"40174","cve":"CVE-2025-40174","epss":"0.001430000","percentile":"0.032120000","score_date":"2026-10-19","updated_at":"2026-10-20 00:13:48"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["arch/x86/mm/tlb.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb","status":"affected","version":"209954cbc7d0ce1a190fc725d20ce303d74d2680","versionType":"git"},{"lessThan":"83b0177a6c4889b3a6e865da5e21b2c9d97d0551","status":"affected","version":"209954cbc7d0ce1a190fc725d20ce303d74d2680","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["arch/x86/mm/tlb.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.14"},{"lessThan":"6.14","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.17.*","status":"unaffected","version":"6.17.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"6.18","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.17.5","versionStartIncluding":"6.14","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18","versionStartIncluding":"6.14","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Fix SMP ordering in switch_mm_irqs_off()\n\nStephen noted that it is possible to not have an smp_mb() between\nthe loaded_mm store and the tlb_gen load in switch_mm(), meaning the\nordering against flush_tlb_mm_range() goes out the window, and it\nbecomes possible for switch_mm() to not observe a recent tlb_gen\nupdate and fail to flush the TLBs.\n\n[ dhansen: merge conflict fixed by Ingo ]"}],"metrics":[{"cvssV3_1":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:L - Triggering the missed TLB flush requires executing code on the target machine — a multithreaded process issuing munmap/mprotect/madvise on one CPU while another thread is context-switched into the same mm on a second CPU. There is no remote or adjacent-network path to `switch_mm_irqs_off()`.\nAC:L - The attacker controls both sides of the race entirely: thread placement via sched_setaffinity, the TLB-flush side via munmap/madvise loops, the context-switch side via yield/futex churn, and even the precondition (CPU bit already set in mm_cpumask so the barrier-providing cpumask_set_cpu is skipped), and can repeat it millions of times per second across all cores. Per attacker-controlled-race guidance this is Low; the bug is also known to fire on real production workloads.\nPR:L - Only an ordinary unprivileged local user account is needed — creating threads, setting CPU affinity, and calling munmap/mprotect/madvise require no capabilities, no namespaces, and no special configuration.\nUI:N - The attacker's own process performs every step; no victim action, mount, or file open is required.\nS:U - The vulnerable component and the impacted resources are both managed by the kernel's own security authority; this is standard kernel memory-corruption/privilege-escalation territory rather than a VM, IOMMU, or hypervisor boundary crossing.\nC:H - Stale TLB entries survive for pages that were unmapped and returned to the page allocator, letting the attacker read whatever those physical pages are reallocated to — another process's or container's anonymous memory, page cache file contents, or kernel slab data — amounting to effectively arbitrary memory disclosure.\nI:H - The retained entries are writable, so the attacker can write into reallocated physical pages, including reused page tables (yielding an arbitrary physical write primitive and root), and can also defeat mprotect(PROT_READ) and copy-on-write break, writing through to pages it should no longer own.\nA:H - Silent corruption of reallocated kernel memory — page tables, slab objects, and page cache — leads to oopses and kernel panics, and the resulting memory corruption is trivially escalated into a full system crash."}]}],"providerMetadata":{"dateUpdated":"2026-08-05T12:08:19.978Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb"},{"url":"https://git.kernel.org/stable/c/83b0177a6c4889b3a6e865da5e21b2c9d97d0551"}],"title":"x86/mm: Fix SMP ordering in switch_mm_irqs_off()","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2025-40174","datePublished":"2025-11-12T10:53:49.859Z","dateReserved":"2025-04-16T07:20:57.177Z","dateUpdated":"2026-08-05T12:08:19.978Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2025-11-12 11:15:47","lastModifiedDate":"2026-10-19 21:10:00","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","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}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2025","CveId":"40174","Ordinal":"1","Title":"x86/mm: Fix SMP ordering in switch_mm_irqs_off()","CVE":"CVE-2025-40174","Year":"2025"},"notes":[{"CveYear":"2025","CveId":"40174","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Fix SMP ordering in switch_mm_irqs_off()\n\nStephen noted that it is possible to not have an smp_mb() between\nthe loaded_mm store and the tlb_gen load in switch_mm(), meaning the\nordering against flush_tlb_mm_range() goes out the window, and it\nbecomes possible for switch_mm() to not observe a recent tlb_gen\nupdate and fail to flush the TLBs.\n\n[ dhansen: merge conflict fixed by Ingo ]","Type":"Description","Title":"x86/mm: Fix SMP ordering in switch_mm_irqs_off()"}]}}}