CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!

Threat and Vulnerability Intelligence Database

Example Searches:

CVE-2024-47141	pinmux: Use sequential access to access desc->pinmux data Description: In the Linux kernel, the following vulnerability has been resolved: pinmux: Use sequential access to access desc->pinmux data When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner. Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer. Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B) pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } } EPSS Score: 0.04% Source: CVE January 12th, 2025 (6 months ago)
CVE-2024-46896	drm/amdgpu: don't access invalid sched Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: don't access invalid sched Since 2320c9e6a768 ("drm/sched: memset() 'job' in drm_sched_job_init()") accessing job->base.sched can produce unexpected results as the initialisation of (*job)->base.sched done in amdgpu_job_alloc is overwritten by the memset. This commit fixes an issue when a CS would fail validation and would be rejected after job->num_ibs is incremented. In this case, amdgpu_ib_free(ring->adev, ...) will be called, which would crash the machine because the ring value is bogus. To fix this, pass a NULL pointer to amdgpu_ib_free(): we can do this because the device is actually not used in this function. The next commit will remove the ring argument completely. (cherry picked from commit 2ae520cb12831d264ceb97c61f72c59d33c0dbd7) EPSS Score: 0.05% Source: CVE January 12th, 2025 (6 months ago)
CVE-2024-45828	i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request Description: In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when the ring is being stopped. Depending on timing between ring stop request completion, interrupt handler removal and code execution this may lead to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run after the io_data pointer is set to NULL in hci_dma_cleanup(). Prevent this my masking the ring interrupts before ring stop request. EPSS Score: 0.04% Source: CVE January 12th, 2025 (6 months ago)
CVE-2024-43098	i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock Description: In the Linux kernel, the following vulnerability has been resolved: i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice. v2: - Modified the title and commit message ============================================ WARNING: possible recursive locking detected 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); * DEADLOCK * May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_ue... EPSS Score: 0.04% Source: CVE January 12th, 2025 (6 months ago)
CVE-2024-41935	f2fs: fix to shrink read extent node in batches Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to shrink read extent node in batches We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue. This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time hold. EPSS Score: 0.05% Source: CVE January 12th, 2025 (6 months ago)
CVE-2024-41932	sched: fix warning in sched_setaffinity Description: In the Linux kernel, the following vulnerability has been resolved: sched: fix warning in sched_setaffinity Commit 8f9ea86fdf99b added some logic to sched_setaffinity that included a WARN when a per-task affinity assignment races with a cpuset update. Specifically, we can have a race where a cpuset update results in the task affinity no longer being a subset of the cpuset. That's fine; we have a fallback to instead use the cpuset mask. However, we have a WARN set up that will trigger if the cpuset mask has no overlap at all with the requested task affinity. This shouldn't be a warning condition; its trivial to create this condition. Reproduced the warning by the following setup: - $PID inside a cpuset cgroup - another thread repeatedly switching the cpuset cpus from 1-2 to just 1 - another thread repeatedly setting the $PID affinity (via taskset) to 2 EPSS Score: 0.04% Source: CVE January 12th, 2025 (6 months ago)
CVE-2024-41149	block: avoid to reuse `hctx` not removed from cpuhp callback list Description: In the Linux kernel, the following vulnerability has been resolved: block: avoid to reuse `hctx` not removed from cpuhp callback list If the 'hctx' isn't removed from cpuhp callback list, we can't reuse it, otherwise use-after-free may be triggered. EPSS Score: 0.05% Source: CVE January 12th, 2025 (6 months ago)
CVE-2024-12587	Contact Form Master <= 1.0.7 - Reflected XSS Description: The Contact Form Master WordPress plugin through 1.0.7 does not sanitise and escape a parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin. EPSS Score: 0.04% Source: CVE January 12th, 2025 (6 months ago)
	Daily Dose of Dark Web Informer - January 11th, 2025 Description: This daily article is intended to make it easier for those who want to stay updated with my regular Dark Web Informer and X/Twitter posts. Source: DarkWebInformer January 11th, 2025 (6 months ago)
	A Threat Actor is Allegedly Selling Access to Australian Magento Stores Description: A Threat Actor is Allegedly Selling Access to Australian Magento Stores Source: DarkWebInformer January 11th, 2025 (6 months ago)