CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46846 – spi: rockchip: Resolve unbalanced runtime PM / system PM handling
https://notcve.org/view.php?id=CVE-2024-46846
In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure. • https://git.kernel.org/stable/c/e882575efc771f130a24322377dc1033551da11d https://git.kernel.org/stable/c/14f970a8d03d882b15b97beb83bd84ac8ba6298c https://git.kernel.org/stable/c/d034bff62faea1a2219e0d2f3d17263265f24087 https://git.kernel.org/stable/c/0efbad8445fbba7896402500a1473450a299a08a https://git.kernel.org/stable/c/be721b451affbecc4ba4eaac3b71cdbdcade1b1b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46845 – tracing/timerlat: Only clear timer if a kthread exists
https://notcve.org/view.php?id=CVE-2024-46845
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Only clear timer if a kthread exists The timerlat tracer can use user space threads to check for osnoise and timer latency. If the program using this is killed via a SIGTERM, the threads are shutdown one at a time and another tracing instance can start up resetting the threads before they are fully closed. That causes the hrtimer assigned to the kthread to be shutdown and freed twice when the dying thread finally closes the file descriptors, causing a use-after-free bug. Only cancel the hrtimer if the associated thread is still around. Also add the interface_lock around the resetting of the tlat_var->kthread. Note, this is just a quick fix that can be backported to stable. A real fix is to have a better synchronization between the shutdown of old threads and the starting of new ones. • https://git.kernel.org/stable/c/e88ed227f639ebcb31ed4e5b88756b47d904584b https://git.kernel.org/stable/c/8c72f0b2c45f21cb8b00fc37f79f632d7e46c2ed https://git.kernel.org/stable/c/8a9d0d405159e9c796ddf771f7cff691c1a2bc1e https://git.kernel.org/stable/c/e6a53481da292d970d1edf0d8831121d1c5e2f0d •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46844 – um: line: always fill *error_out in setup_one_line()
https://notcve.org/view.php?id=CVE-2024-46844
In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line(). • https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5 https://git.kernel.org/stable/c/96301fdc2d533a196197c055af875fe33d47ef84 https://git.kernel.org/stable/c/c8944d449fda9f58c03bd99649b2df09948fc874 https://git.kernel.org/stable/c/43f782c27907f306c664b6614fd6f264ac32cce6 https://git.kernel.org/stable/c/289979d64573f43df1d0e6bc6435de63a0d69cdf https://git.kernel.org/stable/c/ec5b47a370177d79ae7773858042c107e21f8ecc https://git.kernel.org/stable/c/fc843d3837ebcb1c16d3768ef3eb55e25d5331f2 https://git.kernel.org/stable/c/824ac4a5edd3f7494ab1996826c4f47f8 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46843 – scsi: ufs: core: Remove SCSI host only if added
https://notcve.org/view.php?id=CVE-2024-46843
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it. • https://git.kernel.org/stable/c/2f49e05d6b58d660f035a75ff96b77071b4bd5ed https://git.kernel.org/stable/c/3844586e9bd9845140e1078f1e61896b576ac536 https://git.kernel.org/stable/c/7cbff570dbe8907e23bba06f6414899a0fbb2fcc •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46842 – scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info
https://notcve.org/view.php?id=CVE-2024-46842
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts. • https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58 https://git.kernel.org/stable/c/ede596b1434b57c0b3fd5c02b326efe5c54f6e48 •