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-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/ •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26957 – s390/zcrypt: fix reference counting on zcrypt card objects
https://notcve.org/view.php?id=CVE-2024-26957
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix reference counting on zcrypt card objects Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use. This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/zcrypt: corrige el recuento de referencias en los objetos de la tarjeta zcrypt. Las pruebas con tarjetas crypto de conexión en caliente en invitados KVM con compilación del kernel de depuración revelaron un use after free el campo de carga de la estructura zcrypt_card . El motivo fue un manejo de referencia incorrecto del objeto de la tarjeta zcrypt que podría provocar la liberación del objeto de la tarjeta zcrypt mientras aún estaba en uso. • https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058 https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55 https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6 https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000 https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23e • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26954 – ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
https://notcve.org/view.php?id=CVE-2024-26954
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16() If ->NameOffset of smb2_create_req is smaller than Buffer offset of smb2_create_req, slab-out-of-bounds read can happen from smb2_open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2_create_req(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb_strndup_from_utf16() Si ->NameOffset de smb2_create_req es menor que el desplazamiento del búfer de smb2_create_req, puede ocurrir una lectura de slab-out-of-bounds de smb2_open. Este parche establece el valor mínimo del desplazamiento del nombre en el desplazamiento del búfer para validar la longitud del nombre de smb2_create_req(). • https://git.kernel.org/stable/c/3b8da67191e938a63d2736dabb4ac5d337e5de57 https://git.kernel.org/stable/c/4f97e6a9d62cb1fce82fbf4baff44b83221bc178 https://git.kernel.org/stable/c/a80a486d72e20bd12c335bcd38b6e6f19356b0aa •
CVSS: 8.1EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26952 – ksmbd: fix potencial out-of-bounds when buffer offset is invalid
https://notcve.org/view.php?id=CVE-2024-26952
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial out-of-bounds when buffer offset is invalid I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige posibles límites cuando el desplazamiento del búfer no es válido. Encontré posibles límites cuando los campos de desplazamiento del búfer de algunas solicitudes no son válidos. Este parche establece el valor mínimo del campo de compensación del búfer en ->Desplazamiento del búfer para validar la longitud del búfer. • https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63 https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5 https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-125: Out-of-bounds Read •