CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40932 – drm/exynos/vidi: fix memory leak in .get_modes()
https://notcve.org/view.php?id=CVE-2024-40932
In the Linux kernel, the following vulnerability has been resolved: drm/exynos/vidi: fix memory leak in .get_modes() The duplicated EDID is never freed. Fix it. • https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819 https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8 https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003 https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226 https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1 https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224 https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d73 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40931 – mptcp: ensure snd_una is properly initialized on connect
https://notcve.org/view.php?id=CVE-2024-40931
In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_una is properly initialized on connect This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq. • https://git.kernel.org/stable/c/8fd738049ac3d67a937d36577763b47180aae1ad https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726 https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813 https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 https://access.redhat.com/security/cve/CVE-2024-40931 • CWE-400: Uncontrolled Resource Consumption •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40929 – wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
https://notcve.org/view.php?id=CVE-2024-40929
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: check n_ssids before accessing the ssids In some versions of cfg80211, the ssids poinet might be a valid one even though n_ssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking n_ssids first. • https://git.kernel.org/stable/c/c1a7515393e403758a684fd0a2372af466675b15 https://git.kernel.org/stable/c/3c4771091ea8016c8601399078916f722dd8833b https://git.kernel.org/stable/c/f777792952d03bbaf8329fdfa99393a5a33e2640 https://git.kernel.org/stable/c/9e719ae3abad60e245ce248ba3f08148f375a614 https://git.kernel.org/stable/c/29a18d56bd64b95bd10bda4afda512558471382a https://git.kernel.org/stable/c/62e007bdeb91c6879a4652c3426aef1cd9d2937b https://git.kernel.org/stable/c/60d62757df30b74bf397a2847a6db7385c6ee281 https://access.redhat.com/security/cve/CVE-2024-40929 • CWE-125: Out-of-bounds Read •
CVSS: 6.1EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40927 – xhci: Handle TD clearing for multiple streams case
https://notcve.org/view.php?id=CVE-2024-40927
In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. • https://git.kernel.org/stable/c/e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 https://git.kernel.org/stable/c/26460c1afa311524f588e288a4941432f0de6228 https://git.kernel.org/stable/c/633f72cb6124ecda97b641fbc119340bd88d51a9 https://git.kernel.org/stable/c/949be4ec5835e0ccb3e2a8ab0e46179cb5512518 https://git.kernel.org/stable/c/61593dc413c3655e4328a351555235bc3089486a https://git.kernel.org/stable/c/5ceac4402f5d975e5a01c806438eb4e554771577 https://access.redhat.com/security/cve/CVE-2024-40927 https://bugzilla.redhat.com/show_bug.cgi?id=2297511 • CWE-820: Missing Synchronization •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40918 – parisc: Try to fix random segmentation faults in package builds
https://notcve.org/view.php?id=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 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. • https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0 https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20 https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49 •