CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50027 – thermal: core: Free tzp copy along with the thermal zone
https://notcve.org/view.php?id=CVE-2024-50027
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more. • https://git.kernel.org/stable/c/3d439b1a2ad36c8b4ea151c8de25309d60d17407 https://git.kernel.org/stable/c/bdb0d40507c85bee33c2a71fde7b2e857346f112 https://git.kernel.org/stable/c/827a07525c099f54d3b15110408824541ec66b3c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50026 – scsi: wd33c93: Don't use stale scsi_pointer value
https://notcve.org/view.php?id=CVE-2024-50026
In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93: Move the SCSI pointer to private command data") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting. • https://git.kernel.org/stable/c/dbb2da557a6a87c88bbb4b1fef037091b57f701b https://git.kernel.org/stable/c/3afeceda855dea9b85cddd96307d4d17c8742005 https://git.kernel.org/stable/c/e04642a207f1d2ae28a08624c04c67f5681f3451 https://git.kernel.org/stable/c/b60ff1a95c7c386cdd6153de3d7d85edaeabd800 https://git.kernel.org/stable/c/9023ed8d91eb1fcc93e64dc4962f7412b1c4cbec •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50025 – scsi: fnic: Move flush_work initialization out of if block
https://notcve.org/view.php?id=CVE-2024-50025
In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: <IRQ> kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe(). • https://git.kernel.org/stable/c/379a58caa19930e010b7efa1c1f3b9411d3d2ca3 https://git.kernel.org/stable/c/6b7836b80061bf1accc5d78b12bc086aed252388 https://git.kernel.org/stable/c/f30e5f77d2f205ac14d09dec40fd4bb76712f13d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50024 – net: Fix an unsafe loop on the list
https://notcve.org/view.php?id=CVE-2024-50024
In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list. • https://git.kernel.org/stable/c/b8273570f802a7658827dcb077b0b517ba75a289 https://git.kernel.org/stable/c/68ad5da6ca630a276f0a5c924179e57724d00013 https://git.kernel.org/stable/c/1cdec792b2450105b1314c5123a9a0452cb2c2f0 https://git.kernel.org/stable/c/5f03a7f601f33cda1f710611625235dc86fd8a9e https://git.kernel.org/stable/c/3be342e0332a7c83eb26fbb22bf156fdca467a5d https://git.kernel.org/stable/c/49f9b726bf2bf3dd2caf0d27cadf4bc1ccf7a7dd https://git.kernel.org/stable/c/1dae9f1187189bc09ff6d25ca97ead711f7e26f9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50023 – net: phy: Remove LED entry from LEDs list on unregister
https://notcve.org/view.php?id=CVE-2024-50023
In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered. • https://git.kernel.org/stable/c/c938ab4da0eb1620ae3243b0b24c572ddfc318fc https://git.kernel.org/stable/c/143ffa7878e2d9d9c3836ee8304ce4930f7852a3 https://git.kernel.org/stable/c/fba363f4d244269a0ba7abb8df953a244c6749af https://git.kernel.org/stable/c/f50b5d74c68e551667e265123659b187a30fe3a5 •