CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26982 – Squashfs: check the inode number is not the invalid value of zero
https://notcve.org/view.php?id=CVE-2024-26982
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: Squashfs: comprobar que el número de inodo no sea el valor no válido de cero. • https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5 https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395 https://access.redhat.com/security/cve/CVE-2024-26982 https://bugzilla.redhat.com/show_bug.cgi?id=2278337 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26980 – ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf
https://notcve.org/view.php?id=CVE-2024-26980
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb2_allocate_rsp_buf Si ->ProtocolId es SMB2_TRANSFORM_PROTO_NUM, se podría omitir la validación del tamaño de la solicitud smb2. Si el tamaño de la solicitud es menor que sizeof (struct smb2_query_info_req), la lectura de losa fuera de los límites puede ocurrir en smb2_allocate_rsp_buf(). Este parche asigna un búfer de respuesta después de descifrar la solicitud de transformación. smb3_decrypt_req() validará el tamaño de la solicitud de transformación y evitará la losa fuera de los límites en smb2_allocate_rsp_buf(). • https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325 https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248 https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1 https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085 https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26936 – ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
https://notcve.org/view.php?id=CVE-2024-26936
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate request buffer size in smb2_allocate_rsp_buf() The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: validar el tamaño del búfer de solicitud en smb2_allocate_rsp_buf() El búfer de respuesta debe asignarse en smb2_allocate_rsp_buf antes de validar la solicitud. Pero los campos en el payload y el encabezado smb2 se usan en smb2_allocate_rsp_buf(). • https://git.kernel.org/stable/c/8f3d0bf1d0c62b539d54c5b9108a845cff619b99 https://git.kernel.org/stable/c/21ff9d7d223c5c19cb4334009e4c0c83a2f4d674 https://git.kernel.org/stable/c/5c20b242d4fed73a93591e48bfd9772e2322fb11 https://git.kernel.org/stable/c/2c27a64a2bc47d9bfc7c3cf8be14be53b1ee7cb6 https://git.kernel.org/stable/c/17cf0c2794bdb6f39671265aa18aea5c22ee8c4a •
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/ •