CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-43864 – net/mlx5e: Fix CT entry update leaks of modify header context
https://notcve.org/view.php?id=CVE-2024-43864
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks of modify header context The cited commit allocates a new modify header to replace the old one when updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support, modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry is freed, the right modify header context will be freed. • https://git.kernel.org/stable/c/94ceffb48eac7692677d8093dcde6965b70c4b35 https://git.kernel.org/stable/c/daab2cc17b6b6ab158566bba037e9551fd432b59 https://git.kernel.org/stable/c/89064d09c56b44c668509bf793c410484f63f5ad https://git.kernel.org/stable/c/025f2b85a5e5a46df14ecf162c3c80a957a36d0b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43863 – drm/vmwgfx: Fix a deadlock in dma buf fence polling
https://notcve.org/view.php?id=CVE-2024-43863
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock. • https://git.kernel.org/stable/c/2298e804e96eb3635c39519c8287befd92460303 https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237 https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3 https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43862 – net: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex
https://notcve.org/view.php?id=CVE-2024-43862
In the Linux kernel, the following vulnerability has been resolved: net: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex The carrier_lock spinlock protects the carrier detection. While it is held, framer_get_status() is called which in turn takes a mutex. This is not correct and can lead to a deadlock. A run with PROVE_LOCKING enabled detected the issue: [ BUG: Invalid wait context ] ... c204ddbc (&framer->mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78 other info that might help us debug this: context-{4:4} 2 locks held by ifconfig/146: #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664 #1: c2006a40 (&qmc_hdlc->carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98 Avoid the spinlock usage and convert carrier_lock to a mutex. • https://git.kernel.org/stable/c/54762918ca856028d33d1d56d017a4d7706c6196 https://git.kernel.org/stable/c/f223d2b4acb7a45a6e0581cb380e1af1a6dc7ab9 https://git.kernel.org/stable/c/c4d6a347ba7babdf9d90a0eb24048c266cae0532 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43861 – net: usb: qmi_wwan: fix memory leak for not ip packets
https://notcve.org/view.php?id=CVE-2024-43861
In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: fix memory leak for not ip packets Free the unused skb when not ip packets arrive. • https://git.kernel.org/stable/c/c6adf77953bcec0ad63d7782479452464e50f7a3 https://git.kernel.org/stable/c/3c90a69533b5bba73401ef884d033ea49ee99662 https://git.kernel.org/stable/c/37c093449704017870604994ba9b813cdb9475a4 https://git.kernel.org/stable/c/e87f52225e04a7001bf55bbd7a330fa4252327b5 https://git.kernel.org/stable/c/c4251a3deccad852b27e60625f31fba6cc14372f https://git.kernel.org/stable/c/da518cc9b64df391795d9952aed551e0f782e446 https://git.kernel.org/stable/c/f2c353227de14b0289298ffc3ba92058c4768384 https://git.kernel.org/stable/c/c6c5b91424fafc0f83852d961c10c7e43 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43860 – remoteproc: imx_rproc: Skip over memory region when node value is NULL
https://notcve.org/view.php?id=CVE-2024-43860
In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Skip over memory region when node value is NULL In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. [Fixed title to fit within the prescribed 70-75 charcters] • https://git.kernel.org/stable/c/a0ff4aa6f010801b2a61c203c6e09d01b110fddf https://git.kernel.org/stable/c/6884fd0283e0831be153fb8d82d9eda8a55acaaa https://git.kernel.org/stable/c/84beb7738459cac0ff9f8a7c4654b8ff82a702c0 https://git.kernel.org/stable/c/6b50462b473fdccdc0dfad73001147e40ff19a66 https://git.kernel.org/stable/c/4e13b7c23988c0a13fdca92e94296a3bc2ff9f21 https://git.kernel.org/stable/c/9a17cf8b2ce483fa75258bc2cdcf628f24bcf5f8 https://git.kernel.org/stable/c/6c9ea3547fad252fe9ae5d3ed7e066e2085bf3a2 https://git.kernel.org/stable/c/c877a5f5268d4ab8224b9c9fbce3d746e •