CVSS: 6.0EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26900 – md: fix kmemleak of rdev->serial
https://notcve.org/view.php?id=CVE-2024-26900
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 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: corrige kmemleak de rdev->serial Si kobject_add() falla en bind_rdev_to_array(), 'rdev->serial' se asignará y no se liberará, y se produce kmemleak. objeto sin referencia 0xffff88815a350000 (tamaño 49152): comm "mdadm", pid 789, jiffies 4294716910 volcado hexadecimal (primeros 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 ................ retroceso (crc f773277a): [<0000000058b0a453> ] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] loc_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 [<00000 0008b0ad622>] entrada_SYSCALL_64_after_hwframe+0x6c/0x74 A memory leak flaw was found in rdev->serial in the Linux kernel. This issue may lead to a crash. • https://git.kernel.org/stable/c/963c555e75b033202dd76cf6325a7b7c83d08d5f https://git.kernel.org/stable/c/fb5b347efd1bda989846ffc74679d181222fb123 https://git.kernel.org/stable/c/f3a1787dc48213f6caea5ba7d47e0222e7fa34a9 https://git.kernel.org/stable/c/beaf11969fd5cbe6f09cefaa34df1ce8578e8dd9 https://git.kernel.org/stable/c/9fd0198f7ef06ae0d6636fb0578560857dead995 https://git.kernel.org/stable/c/6d32c832a88513f65c2c2c9c75954ee8b387adea https://git.kernel.org/stable/c/4c1021ce46fc2fb6115f7e79d353941e6dcad366 https://git.kernel.org/stable/c/6cf350658736681b9d6b0b6e58c5c76b2 • CWE-401: Missing Release of Memory after Effective Lifetime CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26899 – block: fix deadlock between bd_link_disk_holder and partition scan
https://notcve.org/view.php?id=CVE-2024-26899
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. • https://git.kernel.org/stable/c/1b0a2d950ee2a54aa04fb31ead32144be0bbf690 https://git.kernel.org/stable/c/1e5c5b0abaee7b62a10b9707a62083b71ad21f62 https://git.kernel.org/stable/c/5a87c1f7993bc8ac358a3766bac5dc7126e01e98 https://git.kernel.org/stable/c/03f12122b20b6e6028e9ed69030a49f9cffcbb75 https://access.redhat.com/security/cve/CVE-2024-26899 https://bugzilla.redhat.com/show_bug.cgi?id=2275650 • CWE-667: Improper Locking CWE-833: Deadlock •
CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26898 – aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
https://notcve.org/view.php?id=CVE-2024-26898
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. • https://git.kernel.org/stable/c/7562f876cd93800f2f8c89445f2a563590b24e09 https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99 https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881 https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65 https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4 https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62 https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20a • CWE-416: Use After Free •
CVSS: 4.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26897 – wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
https://notcve.org/view.php?id=CVE-2024-26897
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()). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath9k: retrasa todo ath9k_wmi_event_tasklet() hasta que se complete el inicio. El ath9k_wmi_event_tasklet() usado en ath9k_htc supone que todas las estructuras de datos se han inicializado por completo en el momento de su ejecución. • https://git.kernel.org/stable/c/78c8397132dd4735ac6a7b5a651302f0b9f264ad https://git.kernel.org/stable/c/735aefae7b68025cd04c482a940c0f6fc6797a63 https://git.kernel.org/stable/c/8b3046abc99eefe11438090bcc4ec3a3994b55d0 https://git.kernel.org/stable/c/7bbc1a50a7963f14048f0e54b0b73159f86d4ea3 https://git.kernel.org/stable/c/1bc5461a21c56a36e2a7d81e152b90ce019a3905 https://git.kernel.org/stable/c/f8ff4b4df71e87f609be0cc37d92e918107f9b90 https://git.kernel.org/stable/c/74d0639261dd795dce958d1b14815bdcbb48a715 https://git.kernel.org/stable/c/a015fbf698c8957aa5fbeefc5c59dd2cf • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26896 – wifi: wfx: fix memory leak when starting AP
https://notcve.org/view.php?id=CVE-2024-26896
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 [<fb8a5e38>] __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] [<a4a661cd>] 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 [<f965b9b6>] netlink_sendmsg+0x1e8/0x428 [<aadb8231>] ____sys_sendmsg+0x1e0/0x274 [<d2b5212d>] ___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 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74 [<a2c61343>] __alloc_skb+0xa0/0x170 [<fb8a5e38>] __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] [<a4a661cd>] 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 [<f965b9b6>] netlink_sendmsg+0x1e8/0x428 [<aadb8231>] ____sys_sendmsg+0x1e0/0x274 [<d2b5212d>] ___sys_sendmsg+0x80/0xb4 However, since the kernel is build optimized, it seems the stack is not accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue is obvious in this function: memory allocated by ieee80211_beacon_get() is never released. Fixing this leak makes kmemleak happy. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: wfx: corrige la pérdida de memoria al iniciar AP Kmemleak informó este error: objeto sin referencia 0xd73d1180 (tamaño 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (edad 964.245 s) volcado hexadecimal (primeros 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 ................ rastreo inverso: [<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>] 8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+ 0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] 130 [<6b7c977a>] genl_rcv+0x34/0x44 [ <66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] b4 [<69954f45>] __sys_sendmsg+0x64/0xa8 sin referencia Objeto 0xCE087000 (tamaño 1024): Comm "WPA_Supplicant", PID 1559, Jiffies 13006305 (Edad 964.246s) Volcado hexagonal (Primero 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 00 00 00 00 00 00 00 00 ...@............ retroceso: [<9a993714> ] __kmalloc_track_caller+0x230/0x600 [] kmalloc_reserve.constprop.0+0x30/0x74 [] __alloc_skb+0xa0/0x170 [] __netdev_alloc_skb+0x50/0x180 9fa1d5>] __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>] x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 Sin embargo, dado que el kernel está optimizado, parece que la pila no es precisa. • https://git.kernel.org/stable/c/268bceec1684932e194ae87877dcc73f534d921c https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3 https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3 https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487 https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc • CWE-125: Out-of-bounds Read •