cbcvebase.
CVE-2024-40918
published 2024-07-12

CVE-2024-40918: 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…

PriorityP428medium6.3CVSS 3.1
AVLACHPRLUINSUCNIHAH
EPSS
0.26%
18.2th percentile
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

Affected

14 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.9.7-1 (forky)linux 6.9.7-1 (forky)
linuxlinux
linuxlinux>= 2de8b4cc2051ee1d40eedbcf94de0e7d04507c37 < 5bf196f1936bf93df31112fbdfb78c03537c07b05bf196f1936bf93df31112fbdfb78c03537c07b0
linuxlinux>= 2de8b4cc2051ee1d40eedbcf94de0e7d04507c37 < d66f2607d89f760cdffed88b22f309c895a2af20d66f2607d89f760cdffed88b22f309c895a2af20
linuxlinux>= 2de8b4cc2051ee1d40eedbcf94de0e7d04507c37 < 72d95924ee35c8cd16ef52f912483ee938a34d4972d95924ee35c8cd16ef52f912483ee938a34d49
linuxlinux_kernel< 6.6.356.6.35
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.9.7-16.9.7-1
linuxlinux_kernel>= 0 < 6.9.7-16.9.7-1
linuxlinux_kernel>= 0 < 6.8.0-44.446.8.0-44.44
linuxlinux_kernel>= 6.7 < 6.9.66.9.6
msrccbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0

CVSS provenance

nvdv3.16.3MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
osv6.3MEDIUM
vendor_debian6.3LOW
vendor_msrc6.3MEDIUM
vendor_redhat6.3MEDIUM
vendor_ubuntu5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.