CVE-2024-40918 (GCVE-0-2024-40918)

Vulnerability from cvelistv5 – Published: 2024-07-12 12:25 – Updated: 2026-01-05 10:36
VLAI?
Title
parisc: Try to fix random segmentation faults in package builds
Summary
In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. Another issue is that the present bit in PTEs is racy. 1) PA-RISC caches have a mind of their own and they can speculatively load data and instructions for a page as long as there is a entry in the TLB for the page which allows move-in. TLBs are local to each CPU. Thus, the TLB entry for a page must be purged before flushing the page. This is particularly important on SMP systems. In some of the flush routines, the flush routine would be called and then the TLB entry would be purged. This was because the flush routine needed the TLB entry to do the flush. 2) My initial approach to trying the fix the random faults was to try and use flush_cache_page_if_present for all flush operations. This actually made things worse and led to a couple of hardware lockups. It finally dawned on me that some lines weren't being flushed because the pte check code was racy. This resulted in random inequivalent mappings to physical pages. The __flush_cache_page tmpalias flush sets up its own TLB entry and it doesn't need the existing TLB entry. As long as we can find the pte pointer for the vm page, we can get the pfn and physical address of the page. We can also purge the TLB entry for the page before doing the flush. Further, __flush_cache_page uses a special TLB entry that inhibits cache move-in. When switching page mappings, we need to ensure that lines are removed from the cache. It is not sufficient to just flush the lines to memory as they may come back. This made it clear that we needed to implement all the required flush operations using tmpalias routines. This includes flushes for user and kernel pages. After modifying the code to use tmpalias flushes, it became clear that the random segmentation faults were not fully resolved. The frequency of faults was worse on systems with a 64 MB L2 (PA8900) and systems with more CPUs (rp4440). The warning that I added to flush_cache_page_if_present to detect pages that couldn't be flushed triggered frequently on some systems. Helge and I looked at the pages that couldn't be flushed and found that the PTE was either cleared or for a swap page. Ignoring pages that were swapped out seemed okay but pages with cleared PTEs seemed problematic. I looked at routines related to pte_clear and noticed ptep_clear_flush. The default implementation just flushes the TLB entry. However, it was obvious that on parisc we need to flush the cache page as well. If we don't flush the cache page, stale lines will be left in the cache and cause random corruption. Once a PTE is cleared, there is no way to find the physical address associated with the PTE and flush the associated page at a later time. I implemented an updated change with a parisc specific version of ptep_clear_flush. It fixed the random data corruption on Helge's rp4440 and rp3440, as well as on my c8000. At this point, I realized that I could restore the code where we only flush in flush_cache_page_if_present if the page has been accessed. However, for this, we also need to flush the cache when the accessed bit is cleared in ---truncated---
Severity ?
No CVSS data available.
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 2de8b4cc2051ee1d40eedbcf94de0e7d04507c37 , < 5bf196f1936bf93df31112fbdfb78c03537c07b0 (git)
Affected: 2de8b4cc2051ee1d40eedbcf94de0e7d04507c37 , < d66f2607d89f760cdffed88b22f309c895a2af20 (git)
Affected: 2de8b4cc2051ee1d40eedbcf94de0e7d04507c37 , < 72d95924ee35c8cd16ef52f912483ee938a34d49 (git)
Create a notification for this product.
    Linux Linux Affected: 5.18
Unaffected: 0 , < 5.18 (semver)
Unaffected: 6.6.35 , ≤ 6.6.* (semver)
Unaffected: 6.9.6 , ≤ 6.9.* (semver)
Unaffected: 6.10 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T04:39:55.362Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "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"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-40918",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:05:39.909873Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:33:03.854Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/parisc/include/asm/cacheflush.h",
            "arch/parisc/include/asm/pgtable.h",
            "arch/parisc/kernel/cache.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5bf196f1936bf93df31112fbdfb78c03537c07b0",
              "status": "affected",
              "version": "2de8b4cc2051ee1d40eedbcf94de0e7d04507c37",
              "versionType": "git"
            },
            {
              "lessThan": "d66f2607d89f760cdffed88b22f309c895a2af20",
              "status": "affected",
              "version": "2de8b4cc2051ee1d40eedbcf94de0e7d04507c37",
              "versionType": "git"
            },
            {
              "lessThan": "72d95924ee35c8cd16ef52f912483ee938a34d49",
              "status": "affected",
              "version": "2de8b4cc2051ee1d40eedbcf94de0e7d04507c37",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/parisc/include/asm/cacheflush.h",
            "arch/parisc/include/asm/pgtable.h",
            "arch/parisc/kernel/cache.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.18"
            },
            {
              "lessThan": "5.18",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.35",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.35",
                  "versionStartIncluding": "5.18",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.9.6",
                  "versionStartIncluding": "5.18",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10",
                  "versionStartIncluding": "5.18",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0027t work. On\nreviewing the cache code, I realized that there were two issues\nwhich the existing code didn\u0027t 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\u0027t 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\u0027t 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\u0027t be flushed triggered frequently on some systems.\n\nHelge and I looked at the pages that couldn\u0027t 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\u0027t 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\u0027s 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---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-01-05T10:36:50.560Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-40918",
    "datePublished": "2024-07-12T12:25:00.846Z",
    "dateReserved": "2024-07-12T12:17:45.581Z",
    "dateUpdated": "2026-01-05T10:36:50.560Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "fkie_nvd": {
      "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\u0027t work. On\\nreviewing the cache code, I realized that there were two issues\\nwhich the existing code didn\u0027t 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\u0027t 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\u0027t 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\u0027t be flushed triggered frequently on some systems.\\n\\nHelge and I looked at the pages that couldn\u0027t 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\u0027t 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\u0027s 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---\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: intenta corregir fallas de segmentaci\\u00f3n aleatoria en compilaciones de paquetes. Los sistemas PA-RISC con procesadores PA8800 y PA8900 han tenido problemas con fallas de segmentaci\\u00f3n aleatoria durante muchos a\\u00f1os. Los sistemas con procesadores anteriores son mucho m\\u00e1s estables. Los sistemas con procesadores PA8800 y PA8900 tienen una gran cach\\u00e9 L2 que necesita un vaciado por p\\u00e1gina para un rendimiento decente cuando se vac\\u00eda un rango grande. La cach\\u00e9 combinada en estos sistemas tambi\\u00e9n es m\\u00e1s sensible a alias no equivalentes que las cach\\u00e9s de sistemas anteriores. La mayor\\u00eda de los fallos de segmentaci\\u00f3n aleatoria que he observado parecen ser da\\u00f1os en la memoria asignada mediante mmap y malloc. Mi primer intento de solucionar los fallos aleatorios no funcion\\u00f3. Al revisar el c\\u00f3digo de cach\\u00e9, me di cuenta de que hab\\u00eda dos problemas que el c\\u00f3digo existente no manejaba correctamente. Ambos se relacionan con la entrada de cach\\u00e9. Otro problema es que la actualidad en las PTE es picante. 1) Los cach\\u00e9s PA-RISC tienen mente propia y pueden cargar especulativamente datos e instrucciones para una p\\u00e1gina siempre que haya una entrada en el TLB para la p\\u00e1gina que permita la entrada. Los TLB son locales para cada CPU. Por lo tanto, la entrada TLB de una p\\u00e1gina debe eliminarse antes de eliminarla. Esto es particularmente importante en los sistemas SMP. En algunas de las rutinas de vaciado, se llamar\\u00eda a la rutina de vaciado y luego se purgar\\u00eda la entrada TLB. Esto se deb\\u00eda a que la rutina de lavado necesitaba la entrada TLB para realizar el lavado. 2) Mi enfoque inicial para intentar solucionar las fallas aleatorias fue intentar usar Flush_cache_page_if_present para todas las operaciones de descarga. En realidad, esto empeor\\u00f3 las cosas y provoc\\u00f3 un par de bloqueos de hardware. Finalmente me di cuenta de que algunas l\\u00edneas no se estaban borrando porque el c\\u00f3digo de verificaci\\u00f3n del pte era picante. Esto result\\u00f3 en asignaciones aleatorias no equivalentes a p\\u00e1ginas f\\u00edsicas. La descarga tmpalias __flush_cache_page configura su propia entrada TLB y no necesita la entrada TLB existente. Siempre que podamos encontrar el puntero pte de la p\\u00e1gina vm, podemos obtener el pfn y la direcci\\u00f3n f\\u00edsica de la p\\u00e1gina. Tambi\\u00e9n podemos purgar la entrada TLB de la p\\u00e1gina antes de realizar el vaciado. Adem\\u00e1s, __flush_cache_page utiliza una entrada TLB especial que inhibe la entrada de cach\\u00e9. Al cambiar las asignaciones de p\\u00e1ginas, debemos asegurarnos de que las l\\u00edneas se eliminen del cach\\u00e9. No es suficiente simplemente borrar las l\\u00edneas de la memoria, ya que pueden volver. Esto dej\\u00f3 en claro que necesit\\u00e1bamos implementar todas las operaciones de vaciado necesarias utilizando rutinas tmpalias. Esto incluye vaciados para p\\u00e1ginas de usuario y de kernel. Despu\\u00e9s de modificar el c\\u00f3digo para usar tmpalias vaciados, qued\\u00f3 claro que los errores de segmentaci\\u00f3n aleatoria no se resolvieron por completo. La frecuencia de fallas fue peor en sistemas con 64 MB L2 (PA8900) y sistemas con m\\u00e1s CPU (rp4440). La advertencia que agregu\\u00e9 a Flush_cache_page_if_present para detectar p\\u00e1ginas que no se pod\\u00edan vaciar se activaba con frecuencia en algunos sistemas. Helge y yo miramos las p\\u00e1ginas que no se pod\\u00edan vaciar y descubrimos que la PTE estaba vac\\u00eda o era una p\\u00e1gina de intercambio. Ignorar las p\\u00e1ginas que se intercambiaron parec\\u00eda estar bien, pero las p\\u00e1ginas con PTE borradas parec\\u00edan problem\\u00e1ticas. Mir\\u00e9 rutinas relacionadas con pte_clear y not\\u00e9 ptep_clear_flush. La implementaci\\u00f3n predeterminada simplemente vac\\u00eda la entrada TLB. Sin embargo, era obvio que en Par\\u00eds tambi\\u00e9n necesitamos vaciar la p\\u00e1gina de cach\\u00e9. Si no limpiamos la p\\u00e1gina de cach\\u00e9, quedar\\u00e1n l\\u00edneas obsoletas en la cach\\u00e9 y provocar\\u00e1n da\\u00f1os aleatorios. Una vez que se borra una PTE, no hay forma de encontrar la direcci\\u00f3n f\\u00edsica asociada con la PTE y borrar la p\\u00e1gina asociada m\\u00e1s adelante.  ---truncado---\"}]",
      "id": "CVE-2024-40918",
      "lastModified": "2024-11-21T09:31:51.417",
      "published": "2024-07-12T13:15:14.863",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Awaiting Analysis"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-40918\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-07-12T13:15:14.863\",\"lastModified\":\"2025-09-17T15:37:44.190\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"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\u0027t work. On\\nreviewing the cache code, I realized that there were two issues\\nwhich the existing code didn\u0027t 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\u0027t 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\u0027t 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\u0027t be flushed triggered frequently on some systems.\\n\\nHelge and I looked at the pages that couldn\u0027t 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\u0027t 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\u0027s 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---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: intenta corregir fallas de segmentaci\u00f3n aleatoria en compilaciones de paquetes. Los sistemas PA-RISC con procesadores PA8800 y PA8900 han tenido problemas con fallas de segmentaci\u00f3n aleatoria durante muchos a\u00f1os. Los sistemas con procesadores anteriores son mucho m\u00e1s estables. Los sistemas con procesadores PA8800 y PA8900 tienen una gran cach\u00e9 L2 que necesita un vaciado por p\u00e1gina para un rendimiento decente cuando se vac\u00eda un rango grande. La cach\u00e9 combinada en estos sistemas tambi\u00e9n es m\u00e1s sensible a alias no equivalentes que las cach\u00e9s de sistemas anteriores. La mayor\u00eda de los fallos de segmentaci\u00f3n aleatoria que he observado parecen ser da\u00f1os en la memoria asignada mediante mmap y malloc. Mi primer intento de solucionar los fallos aleatorios no funcion\u00f3. Al revisar el c\u00f3digo de cach\u00e9, me di cuenta de que hab\u00eda dos problemas que el c\u00f3digo existente no manejaba correctamente. Ambos se relacionan con la entrada de cach\u00e9. Otro problema es que la actualidad en las PTE es picante. 1) Los cach\u00e9s PA-RISC tienen mente propia y pueden cargar especulativamente datos e instrucciones para una p\u00e1gina siempre que haya una entrada en el TLB para la p\u00e1gina que permita la entrada. Los TLB son locales para cada CPU. Por lo tanto, la entrada TLB de una p\u00e1gina debe eliminarse antes de eliminarla. Esto es particularmente importante en los sistemas SMP. En algunas de las rutinas de vaciado, se llamar\u00eda a la rutina de vaciado y luego se purgar\u00eda la entrada TLB. Esto se deb\u00eda a que la rutina de lavado necesitaba la entrada TLB para realizar el lavado. 2) Mi enfoque inicial para intentar solucionar las fallas aleatorias fue intentar usar Flush_cache_page_if_present para todas las operaciones de descarga. En realidad, esto empeor\u00f3 las cosas y provoc\u00f3 un par de bloqueos de hardware. Finalmente me di cuenta de que algunas l\u00edneas no se estaban borrando porque el c\u00f3digo de verificaci\u00f3n del pte era picante. Esto result\u00f3 en asignaciones aleatorias no equivalentes a p\u00e1ginas f\u00edsicas. La descarga tmpalias __flush_cache_page configura su propia entrada TLB y no necesita la entrada TLB existente. Siempre que podamos encontrar el puntero pte de la p\u00e1gina vm, podemos obtener el pfn y la direcci\u00f3n f\u00edsica de la p\u00e1gina. Tambi\u00e9n podemos purgar la entrada TLB de la p\u00e1gina antes de realizar el vaciado. Adem\u00e1s, __flush_cache_page utiliza una entrada TLB especial que inhibe la entrada de cach\u00e9. Al cambiar las asignaciones de p\u00e1ginas, debemos asegurarnos de que las l\u00edneas se eliminen del cach\u00e9. No es suficiente simplemente borrar las l\u00edneas de la memoria, ya que pueden volver. Esto dej\u00f3 en claro que necesit\u00e1bamos implementar todas las operaciones de vaciado necesarias utilizando rutinas tmpalias. Esto incluye vaciados para p\u00e1ginas de usuario y de kernel. Despu\u00e9s de modificar el c\u00f3digo para usar tmpalias vaciados, qued\u00f3 claro que los errores de segmentaci\u00f3n aleatoria no se resolvieron por completo. La frecuencia de fallas fue peor en sistemas con 64 MB L2 (PA8900) y sistemas con m\u00e1s CPU (rp4440). La advertencia que agregu\u00e9 a Flush_cache_page_if_present para detectar p\u00e1ginas que no se pod\u00edan vaciar se activaba con frecuencia en algunos sistemas. Helge y yo miramos las p\u00e1ginas que no se pod\u00edan vaciar y descubrimos que la PTE estaba vac\u00eda o era una p\u00e1gina de intercambio. Ignorar las p\u00e1ginas que se intercambiaron parec\u00eda estar bien, pero las p\u00e1ginas con PTE borradas parec\u00edan problem\u00e1ticas. Mir\u00e9 rutinas relacionadas con pte_clear y not\u00e9 ptep_clear_flush. La implementaci\u00f3n predeterminada simplemente vac\u00eda la entrada TLB. Sin embargo, era obvio que en Par\u00eds tambi\u00e9n necesitamos vaciar la p\u00e1gina de cach\u00e9. Si no limpiamos la p\u00e1gina de cach\u00e9, quedar\u00e1n l\u00edneas obsoletas en la cach\u00e9 y provocar\u00e1n da\u00f1os aleatorios. Una vez que se borra una PTE, no hay forma de encontrar la direcci\u00f3n f\u00edsica asociada con la PTE y borrar la p\u00e1gina asociada m\u00e1s adelante.  ---truncado---\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H\",\"baseScore\":6.3,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.0,\"impactScore\":5.2}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"6.6.35\",\"matchCriteriaId\":\"D8F520E1-506C-47D4-A31B-142545B8B199\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.9.6\",\"matchCriteriaId\":\"0ABBBA1D-F79D-4BDB-AA41-D1EDCC4A6975\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"2EBB4392-5FA6-4DA9-9772-8F9C750109FA\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"331C2F14-12C7-45D5-893D-8C52EE38EA10\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"3173713D-909A-4DD3-9DD4-1E171EB057EE\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"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\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T04:39:55.362Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"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\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-09-11T12:42:14.322Z\"}}], \"cna\": {\"title\": \"parisc: Try to fix random segmentation faults in package builds\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"2de8b4cc2051ee1d40eedbcf94de0e7d04507c37\", \"lessThan\": \"5bf196f1936bf93df31112fbdfb78c03537c07b0\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"2de8b4cc2051ee1d40eedbcf94de0e7d04507c37\", \"lessThan\": \"d66f2607d89f760cdffed88b22f309c895a2af20\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"2de8b4cc2051ee1d40eedbcf94de0e7d04507c37\", \"lessThan\": \"72d95924ee35c8cd16ef52f912483ee938a34d49\", \"versionType\": \"git\"}], \"programFiles\": [\"arch/parisc/include/asm/cacheflush.h\", \"arch/parisc/include/asm/pgtable.h\", \"arch/parisc/kernel/cache.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.18\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.18\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.6.35\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.9.6\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.9.*\"}, {\"status\": \"unaffected\", \"version\": \"6.10\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"arch/parisc/include/asm/cacheflush.h\", \"arch/parisc/include/asm/pgtable.h\", \"arch/parisc/kernel/cache.c\"], \"defaultStatus\": \"affected\"}], \"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\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"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\u0027t work. On\\nreviewing the cache code, I realized that there were two issues\\nwhich the existing code didn\u0027t 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\u0027t 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\u0027t 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\u0027t be flushed triggered frequently on some systems.\\n\\nHelge and I looked at the pages that couldn\u0027t 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\u0027t 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\u0027s 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---\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6.35\", \"versionStartIncluding\": \"5.18\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.9.6\", \"versionStartIncluding\": \"5.18\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.10\", \"versionStartIncluding\": \"5.18\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-01-05T10:36:50.560Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-40918\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-01-05T10:36:50.560Z\", \"dateReserved\": \"2024-07-12T12:17:45.581Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-07-12T12:25:00.846Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.