CVSS: -EPSS: %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: %CPEs: 4EXPL: 0CVE-2024-46847 – mm: vmalloc: ensure vmap_block is initialised before adding to queue
https://notcve.org/view.php?id=CVE-2024-46847
In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: ensure vmap_block is initialised before adding to queue Commit 8c61291fd850 ("mm: fix incorrect vbq reference in purge_fragmented_block") extended the 'vmap_block' structure to contain a 'cpu' field which is set at allocation time to the id of the initialising CPU. When a new 'vmap_block' is being instantiated by new_vmap_block(), the partially initialised structure is added to the local 'vmap_block_queue' xarray before the 'cpu' field has been initialised. If another CPU is concurrently walking the xarray (e.g. via vm_unmap_aliases()), then it may perform an out-of-bounds access to the remote queue thanks to an uninitialised index. This has been observed as UBSAN errors in Android: | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP | | Call trace: | purge_fragmented_block+0x204/0x21c | _vm_unmap_aliases+0x170/0x378 | vm_unmap_aliases+0x1c/0x28 | change_memory_common+0x1dc/0x26c | set_memory_ro+0x18/0x24 | module_enable_ro+0x98/0x238 | do_init_module+0x1b0/0x310 Move the initialisation of 'vb->cpu' in new_vmap_block() ahead of the addition to the xarray. • https://git.kernel.org/stable/c/88e0ad40d08a73a74c597e69f4cd2d1fba3838b5 https://git.kernel.org/stable/c/8c61291fd8500e3b35c7ec0c781b273d8cc96cde https://git.kernel.org/stable/c/9983b81579be3403f5cc44b11f66c6c8bea6547f https://git.kernel.org/stable/c/1b2770e27d6d952f491bb362b657e5b2713c3efd https://git.kernel.org/stable/c/6cf74e0e5e3ab5d5c9defb4c73dad54d52224671 https://git.kernel.org/stable/c/3e3de7947c751509027d26b679ecd243bc9db255 •
CVSS: -EPSS: %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: %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: %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 •