CVSS: 6.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43865 – s390/fpu: Re-add exception handling in load_fpu_state()
https://notcve.org/view.php?id=CVE-2024-43865
In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Re-add exception handling in load_fpu_state() With the recent rewrite of the fpu code exception handling for the lfpc instruction within load_fpu_state() was erroneously removed. Add it again to prevent that loading invalid floating point register values cause an unhandled specification exception. • https://git.kernel.org/stable/c/8c09871a950a3fe686e0e27fd4193179c5f74f37 https://git.kernel.org/stable/c/494b14138201f07343e5488db6360c828fcc8cf6 https://git.kernel.org/stable/c/4734406c39238cbeafe66f0060084caa3247ff53 https://access.redhat.com/security/cve/CVE-2024-43865 https://bugzilla.redhat.com/show_bug.cgi?id=2306357 • CWE-703: Improper Check or Handling of Exceptional Conditions •
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 •