{"dataType": "CVE_RECORD", "dataVersion": "5.1", "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": "2024-11-05T09:33:07.635Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:33:07.635Z"}, "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---"}], "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": "1da177e4c3f4", "lessThan": "5bf196f1936b", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "d66f2607d89f", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "72d95924ee35", "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": "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"}]}], "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-9e1c9544281a"}}, "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"}}]}}

{"dataType": "CVE_RECORD", "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": "1da177e4c3f4", "lessThan": "5bf196f1936b", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "d66f2607d89f", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "72d95924ee35", "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": "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-9e1c9544281a"}, "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---"}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:33:07.635Z"}}}, "cveMetadata": {"cveId": "CVE-2024-40918", "state": "PUBLISHED", "dateUpdated": "2024-11-05T09:33:07.635Z", "dateReserved": "2024-07-12T12:17:45.581Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-07-12T12:25:00.846Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"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'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---"}, {"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-07-12T16:34:58.687", "metrics": {}, "published": "2024-07-12T13:15:14.863", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "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"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: parisc: Try to fix random segmentation faults in package builds", "id": "2297502", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2297502"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.4", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-99", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nparisc: Try to fix random segmentation faults in package builds\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.\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.\nThe majority of random segmentation faults that I have looked at\nappear to be memory corruption in memory allocated using mmap and\nmalloc.\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.\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.\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.\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.\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.\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.\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.\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).\nThe warning that I added to flush_cache_page_if_present to detect\npages that couldn't be flushed triggered frequently on some systems.\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.\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.\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.\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---"], "name": "CVE-2024-40918", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-07-12T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-40918\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-40918\nhttps://lore.kernel.org/linux-cve-announce/2024071212-CVE-2024-40918-1830@gregkh/T"], "threat_severity": "Low", "upstream_fix": "kernel 6.6.35, kernel 6.9.6, kernel 6.10-rc4"}