CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26964 – usb: xhci: Add error handling in xhci_map_urb_for_dma
https://notcve.org/view.php?id=CVE-2024-26964
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: agregar manejo de errores en xhci_map_urb_for_dma Actualmente, xhci_map_urb_for_dma() crea un búfer temporal y copia la lista SG en el nuevo búfer lineal. Pero si kzalloc_node() falla, entonces el siguiente sg_pcopy_to_buffer() puede provocar un fallo ya que intenta memcpy al puntero NULL. Entonces devuelve -ENOMEM si kzalloc devuelve un puntero nulo. • https://git.kernel.org/stable/c/2017a1e58472a27e532b9644b4a61dfe18f6baac https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4 https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757 https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052 https://access.redhat.com/security/cve/CVE-2024-26964 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26962 – dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape
https://notcve.org/view.php?id=CVE-2024-26962
In the Linux kernel, the following vulnerability has been resolved: dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang: 1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set; After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 This is because reshape can't make progress. For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more: 1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'. However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm-raid456, md/raid456: soluciona un punto muerto para dm-raid456 mientras io concurre con reshape. Para raid456, si el reshape todavía está en progreso, entonces IO en la posición de reshape esperará remodelar para progresar. • https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1 https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304 https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677 https://access.redhat.com/security/cve/CVE-2024-26962 https://bugzilla.redhat.com/show_bug.cgi?id=2278174 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26961 – mac802154: fix llsec key resources release in mac802154_llsec_key_del
https://notcve.org/view.php?id=CVE-2024-26961
In the Linux kernel, the following vulnerability has been resolved: mac802154: fix llsec key resources release in mac802154_llsec_key_del mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion: refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del(): unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu(). Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses. Found by Linux Verification Center (linuxtesting.org). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac802154: corrige la liberación de recursos de clave llsec en mac802154_llsec_key_del mac802154_llsec_key_del() puede liberar recursos de una clave directamente sin seguir las reglas de RCU para esperar antes del final de un período de gracia. Esto puede llevar a un use-after-free en caso de que llsec_lookup_key() esté recorriendo la lista de claves en paralelo con una eliminación de clave: refcount_t: suma en 0; use-after-free. • https://git.kernel.org/stable/c/5d637d5aabd85132bd85779677d8acb708e0ed90 https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531 https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821 https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88 https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1 https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b • CWE-459: Incomplete Cleanup •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26960 – mm: swap: fix race between free_swap_and_cache() and swapoff()
https://notcve.org/view.php?id=CVE-2024-26960
In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. • https://git.kernel.org/stable/c/7c00bafee87c7bac7ed9eced7c161f8e5332cb4e https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39 https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26958 – nfs: fix UAF in direct writes
https://notcve.org/view.php?id=CVE-2024-26958
In the Linux kernel, the following vulnerability has been resolved: nfs: fix UAF in direct writes In production we have been hitting the following warning consistently ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? • https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5 https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3 https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605 https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95 https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af https://lists.debian.org/debian-lts-announce/2024/06/ •