CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!
Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
CVE-2024-26902 |
Description: In the Linux kernel, the following vulnerability has been resolved:
perf: RISCV: Fix panic on pmu overflow handler
(1 << idx) of int is not desired when setting bits in unsigned long
overflowed_ctrs, use BIT() instead. This panic happens when running
'perf record -e branches' on sophgo sg2042.
[ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[ 273.320851] Oops [#1]
[ 273.323179] Modules linked in:
[ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9
[ 273.332521] Hardware name: Sophgo Mango (DT)
[ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62
[ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e
[ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0
[ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978
[ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70
[ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000
[ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015
[ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a
[ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0
[ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210
[ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098
[ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff...
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26901 |
Description: In the Linux kernel, the following vulnerability has been resolved:
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].
[1]
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
_copy_to_user+0xbc/0x100 lib/usercopy.c:40
copy_to_user include/linux/uaccess.h:191 [inline]
do_sys_name_to_handle fs/fhandle.c:73 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc+0x121/0x3c0 mm/slab_common.c:1020
kmalloc include/linux/slab.h:604 [inline]
do_sys_name_to_handle fs/fhandle.c:39 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240"
Per Chuck Lever's suggestio...
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26900 |
Description: In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev->serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
comm "mdadm", pid 789, jiffies 4294716910
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc f773277a):
[<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
[<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
[<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
[<00000000f206d60a>] kvmalloc_node+0x74/0x150
[<0000000034bf3363>] rdev_init_serial+0x67/0x170
[<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
[<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
[<0000000073c28560>] md_add_new_disk+0x400/0x9f0
[<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
[<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
[<0000000085086a11>] vfs_ioctl+0x22/0x60
[<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
[<00000000e54e675e>] do_syscall_64+0x71/0x150
[<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26899 |
Description: In the Linux kernel, the following vulnerability has been resolved:
block: fix deadlock between bd_link_disk_holder and partition scan
'open_mutex' of gendisk is used to protect open/close block devices. But
in bd_link_disk_holder(), it is used to protect the creation of symlink
between holding disk and slave bdev, which introduces some issues.
When bd_link_disk_holder() is called, the driver is usually in the process
of initialization/modification and may suspend submitting io. At this
time, any io hold 'open_mutex', such as scanning partitions, can cause
deadlocks. For example, in raid:
T1 T2
bdev_open_by_dev
lock open_mutex [1]
...
efi_partition
...
md_submit_bio
md_ioctl mddev_syspend
-> suspend all io
md_add_new_disk
bind_rdev_to_array
bd_link_disk_holder
try lock open_mutex [2]
md_handle_request
-> wait mddev_resume
T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume
mddev, but T2 waits for open_mutex held by T1. Deadlock occurs.
Fix it by introducing a local mutex 'blk_holder_mutex' to replace
'open_mutex'.
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26898 |
Description: In the Linux kernel, the following vulnerability has been resolved:
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
This patch is against CVE-2023-6270. The description of cve is:
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
`struct net_device`, and a use-after-free can be triggered by racing
between the free on the struct and the access through the `skbtxq`
global queue. This could lead to a denial of service condition or
potential code execution.
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
code is finished. But the net_device ifp will still be used in
later tx()->dev_queue_xmit() in kthread. Which means that the
dev_put(ifp) should NOT be called in the success path of skb
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
use-after-free because the net_device is freed.
This patch removed the dev_put(ifp) in the success path in
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26897 |
Description: In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
structures have been fully initialised by the time it runs. However, because of
the order in which things are initialised, this is not guaranteed to be the
case, because the device is exposed to the USB subsystem before the ath9k driver
initialisation is completed.
We already committed a partial fix for this in commit:
8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
tasklet, pairing it with an "initialisation complete" bit in the TX struct. It
seems syzbot managed to trigger the race for one of the other commands as well,
so let's just move the existing synchronisation bit to cover the whole
tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
ath9k_tx_init()).
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26896 |
Description: In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix memory leak when starting AP
Kmemleak reported this error:
unreferenced object 0xd73d1180 (size 184):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
backtrace:
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
[<127bdd74>] __alloc_skb+0x144/0x170
[] __netdev_alloc_skb+0x50/0x180
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
[] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
[<47bd8b68>] genl_rcv_msg+0x198/0x378
[<453ef796>] netlink_rcv_skb+0xd0/0x130
[<6b7c977a>] genl_rcv+0x34/0x44
[<66b2d04d>] netlink_unicast+0x1b4/0x258
[] netlink_sendmsg+0x1e8/0x428
[] ____sys_sendmsg+0x1e0/0x274
[] ___sys_sendmsg+0x80/0xb4
[<69954f45>] __sys_sendmsg+0x64/0xa8
unreferenced object 0xce087000 (size 1024):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10 00 07 40 00 00 00 00 ...
EPSS Score: 0.05%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26895 |
Description: In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
wilc_netdev_cleanup currently triggers a KASAN warning, which can be
observed on interface registration error path, or simply by
removing the module/unbinding device from driver:
echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind
==================================================================
BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
Read of size 4 at addr c54d1ce8 by task sh/86
CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
Hardware name: Atmel SAMA5
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x58
dump_stack_lvl from print_report+0x154/0x500
print_report from kasan_report+0xac/0xd8
kasan_report from wilc_netdev_cleanup+0x508/0x5cc
wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
wilc_bus_remove from spi_remove+0x8c/0xac
spi_remove from device_release_driver_internal+0x434/0x5f8
device_release_driver_internal from unbind_store+0xbc/0x108
unbind_store from kernfs_fop_write_iter+0x398/0x584
kernfs_fop_write_iter from vfs_write+0x728/0xf88
vfs_write from ksys_write+0x110/0x1e4
ksys_write from ret_fast_syscall+0x0/0x1c
[...]
Allocated by task 1:
kasan_save_track+0x30/0x5c
__kasan_kmalloc+0x8c/0x94
__kmalloc_node+0x1cc/0x3e4
kvmalloc_node+0x48/0x180
alloc_netdev_mqs+0x68/0x11dc
alloc_etherdev_mqs+0x28/0x34
wilc_netdev_ifc_init+0x34/0x...
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26894 |
Description: In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[] kmalloc_trace+0x29d/0x340
[] acpi_processor_power_init+0xf3/0x1c0
[] __acpi_processor_start+0xd3/0xf0
[] acpi_processor_start+0x2c/0x50
[] really_probe+0xe2/0x480
[] __driver_probe_device+0x78/0x160
[] driver_probe_device+0x1f/0x90
[] __driver_attach+0xce/0x1c0
[] bus_for_each_dev+0x70/0xc0
[] bus_add_driver+0x112/0x210
[] driver_register+0x55/0x100
[] acpi_processor_driver_init+0x3b/0xc0
[] do_one_initcall+0x41/0x300
[] kernel_init_freeable+0x320/0x470
[] kernel_init+0x16/0x1b0
[] ret_from_fork+0x2d/0x50
Fix this by freeing the CPU idle device after unregistering it.
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|
|
CVE-2024-26893 |
Description: In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix double free in SMC transport cleanup path
When the generic SCMI code tears down a channel, it calls the chan_free
callback function, defined by each transport. Since multiple protocols
might share the same transport_info member, chan_free() might want to
clean up the same member multiple times within the given SCMI transport
implementation. In this case, it is SMC transport. This will lead to a NULL
pointer dereference at the second time:
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
| arm-scmi firmware:scmi: unable to communicate with SCMI
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
| Mem abort info:
| ESR = 0x0000000096000004
| EC = 0x25: DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| FSC = 0x04: level 0 translation fault
| Data abort info:
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g45...
EPSS Score: 0.04%
December 20th, 2024 (7 months ago)
|