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: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40924 – drm/i915/dpt: Make DPT object unshrinkable
https://notcve.org/view.php?id=CVE-2024-40924
In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Make DPT object unshrinkable In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->bound_list. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic. [vsyrjala: Add TODO comment] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c) • https://git.kernel.org/stable/c/0dc987b699ce4266450d407d6d79d41eab88c5d0 https://git.kernel.org/stable/c/327280149066f0e5f2e50356b5823f76dabfe86e https://git.kernel.org/stable/c/7a9883be3b98673333eec65c4a21cc18e60292eb https://git.kernel.org/stable/c/a2552020fb714ff357182c3c179abfac2289f84d https://git.kernel.org/stable/c/43e2b37e2ab660c3565d4cff27922bc70e79c3f1 https://access.redhat.com/security/cve/CVE-2024-40924 https://bugzilla.redhat.com/show_bug.cgi?id=2297508 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •