{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2024-40918", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-07-12T12:17:45.581Z", "datePublished": "2024-07-12T12:25:00.846Z", "dateUpdated": "2026-08-05T11:33:59.904Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T11:33:59.904Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Try to fix random segmentation faults in package builds\n\nPA-RISC systems with PA8800 and PA8900 processors have had problems\nwith random segmentation faults for many years. Systems with earlier\nprocessors are much more stable.\n\nSystems with PA8800 and PA8900 processors have a large L2 cache which\nneeds per page flushing for decent performance when a large range is\nflushed. The combined cache in these systems is also more sensitive to\nnon-equivalent aliases than the caches in earlier systems.\n\nThe majority of random segmentation faults that I have looked at\nappear to be memory corruption in memory allocated using mmap and\nmalloc.\n\nMy first attempt at fixing the random faults didn't work. On\nreviewing the cache code, I realized that there were two issues\nwhich the existing code didn't handle correctly. Both relate\nto cache move-in. Another issue is that the present bit in PTEs\nis racy.\n\n1) PA-RISC caches have a mind of their own and they can speculatively\nload data and instructions for a page as long as there is a entry in\nthe TLB for the page which allows move-in. TLBs are local to each\nCPU. Thus, the TLB entry for a page must be purged before flushing\nthe page. This is particularly important on SMP systems.\n\nIn some of the flush routines, the flush routine would be called\nand then the TLB entry would be purged. This was because the flush\nroutine needed the TLB entry to do the flush.\n\n2) My initial approach to trying the fix the random faults was to\ntry and use flush_cache_page_if_present for all flush operations.\nThis actually made things worse and led to a couple of hardware\nlockups. It finally dawned on me that some lines weren't being\nflushed because the pte check code was racy. This resulted in\nrandom inequivalent mappings to physical pages.\n\nThe __flush_cache_page tmpalias flush sets up its own TLB entry\nand it doesn't need the existing TLB entry. As long as we can find\nthe pte pointer for the vm page, we can get the pfn and physical\naddress of the page. We can also purge the TLB entry for the page\nbefore doing the flush. Further, __flush_cache_page uses a special\nTLB entry that inhibits cache move-in.\n\nWhen switching page mappings, we need to ensure that lines are\nremoved from the cache. It is not sufficient to just flush the\nlines to memory as they may come back.\n\nThis made it clear that we needed to implement all the required\nflush operations using tmpalias routines. This includes flushes\nfor user and kernel pages.\n\nAfter modifying the code to use tmpalias flushes, it became clear\nthat the random segmentation faults were not fully resolved. The\nfrequency of faults was worse on systems with a 64 MB L2 (PA8900)\nand systems with more CPUs (rp4440).\n\nThe warning that I added to flush_cache_page_if_present to detect\npages that couldn't be flushed triggered frequently on some systems.\n\nHelge and I looked at the pages that couldn't be flushed and found\nthat the PTE was either cleared or for a swap page. Ignoring pages\nthat were swapped out seemed okay but pages with cleared PTEs seemed\nproblematic.\n\nI looked at routines related to pte_clear and noticed ptep_clear_flush.\nThe default implementation just flushes the TLB entry. However, it was\nobvious that on parisc we need to flush the cache page as well. If\nwe don't flush the cache page, stale lines will be left in the cache\nand cause random corruption. Once a PTE is cleared, there is no way\nto find the physical address associated with the PTE and flush the\nassociated page at a later time.\n\nI implemented an updated change with a parisc specific version of\nptep_clear_flush. It fixed the random data corruption on Helge's rp4440\nand rp3440, as well as on my c8000.\n\nAt this point, I realized that I could restore the code where we only\nflush in flush_cache_page_if_present if the page has been accessed.\nHowever, for this, we also need to flush the cache when the accessed\nbit is cleared in\n---truncated---" } ], "metrics": [ { "cvssV3_1": { "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" }, "scenarios": [ { "lang": "en", "value": "AV:L - The faulty cache-flush primitives are driven by memory-management operations (COW faults, munmap, mremap, reclaim, ptrace) that require local execution on the affected parisc system. There is no remote protocol path that reaches the arch cache code directly.\nAC:L - An unprivileged local process reliably triggers stale-cache-line corruption simply by running a heavy mmap/fork/COW workload — the commit reports ordinary package builds hitting it routinely — and a multi-threaded attacker controls both sides of the racy PTE check plus physical page-frame reuse via standard page-spray grooming.\nPR:L - Only an ordinary unprivileged local account is needed; the vulnerable paths (wp_page_copy, try_to_unmap, mremap, userfaultfd, ptrace) are reachable with no capability whatsoever.\nUI:N - The attacker's own memory workload triggers the missed flushes; no action by any other user or victim process is required.\nS:U - The corruption occurs within the kernel's own memory management on the same host, which is the standard unchanged-scope case for kernel memory-corruption issues.\nC:H - Stale cache lines survive across page-frame reuse, so data belonging to a previously-mapped page — another process's memory, page cache contents, or kernel data — can be read through the new owner's alias, giving cross-boundary disclosure of arbitrary physical memory contents.\nI:H - Unflushed dirty lines for a freed page are written back over whatever now occupies that frame, silently corrupting other processes' memory, the page cache, slab objects, and kernel structures including page tables — an arbitrary-write primitive suitable for privilege escalation.\nA:H - The documented effect is random segmentation faults and memory corruption; when the corrupted frame holds kernel data the result is an oops or panic, and the commit describes cache incoherency severe enough to produce hardware lockups." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "arch/parisc/include/asm/cacheflush.h", "arch/parisc/include/asm/pgtable.h", "arch/parisc/kernel/cache.c" ], "versions": [ { "version": "2de8b4cc2051ee1d40eedbcf94de0e7d04507c37", "lessThan": "5bf196f1936bf93df31112fbdfb78c03537c07b0", "status": "affected", "versionType": "git" }, { "version": "2de8b4cc2051ee1d40eedbcf94de0e7d04507c37", "lessThan": "d66f2607d89f760cdffed88b22f309c895a2af20", "status": "affected", "versionType": "git" }, { "version": "2de8b4cc2051ee1d40eedbcf94de0e7d04507c37", "lessThan": "72d95924ee35c8cd16ef52f912483ee938a34d49", "status": "affected", "versionType": "git" } ] }, { "product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "arch/parisc/include/asm/cacheflush.h", "arch/parisc/include/asm/pgtable.h", "arch/parisc/kernel/cache.c" ], "versions": [ { "version": "5.18", "status": "affected" }, { "version": "0", "lessThan": "5.18", "status": "unaffected", "versionType": "semver" }, { "version": "6.6.35", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.9.6", "lessThanOrEqual": "6.9.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.10", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix" } ] } ], "cpeApplicability": [ { "nodes": [ { "operator": "OR", "negate": false, "cpeMatch": [ { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.18", "versionEndExcluding": "6.6.35" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.18", "versionEndExcluding": "6.9.6" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.18", "versionEndExcluding": "6.10" } ] } ] } ], "references": [ { "url": "https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0" }, { "url": "https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20" }, { "url": "https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49" } ], "title": "parisc: Try to fix random segmentation faults in package builds", "x_generator": { "engine": "bippy-1.2.0" } }, "adp": [ { "providerMetadata": { "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T04:39:55.362Z" }, "title": "CVE Program Container", "references": [ { "url": "https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0", "tags": [ "x_transferred" ] }, { "url": "https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20", "tags": [ "x_transferred" ] }, { "url": "https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49", "tags": [ "x_transferred" ] } ] }, { "metrics": [ { "other": { "type": "ssvc", "content": { "id": "CVE-2024-40918", "role": "CISA Coordinator", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "partial" } ], "version": "2.0.3", "timestamp": "2024-09-10T17:05:39.909873Z" } } } ], "title": "CISA ADP Vulnrichment", "providerMetadata": { "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-11T17:33:03.854Z" } } ] } }