CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46848 – perf/x86/intel: Limit the period on Haswell
https://notcve.org/view.php?id=CVE-2024-46848
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Limit the period on Haswell Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? • https://git.kernel.org/stable/c/3a632cb229bfb18b6d09822cc842451ea46c013e https://git.kernel.org/stable/c/15210b7c8caff4929f25d049ef8404557f8ae468 https://git.kernel.org/stable/c/0eaf812aa1506704f3b78be87036860e5d0fe81d https://git.kernel.org/stable/c/8717dc35c0e5896f4110f4b3882f7ff787a5f73d https://git.kernel.org/stable/c/25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b •
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 •