CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26981 – nilfs2: fix OOB in nilfs_set_de_type
https://notcve.org/view.php?id=CVE-2024-26981
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige OOB en nilfs_set_de_type El tamaño de la matriz nilfs_type_by_mode en el archivo fs/nilfs2/dir.c se define como "S_IFMT >> S_SHIFT", pero la función nilfs_set_de_type() , que utiliza esta matriz, especifica el índice a leer de la matriz de la misma manera que "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t modo = inodo->i_mode; de->tipo_archivo = nilfs_type_by_mode[(modo & S_IFMT)>>S_SHIFT]; // oob } Sin embargo, cuando el índice se determina de esta manera, se produce un error fuera de los límites (OOB) al hacer referencia a un índice que es 1 mayor que el tamaño de la matriz cuando la condición "modo & S_IFMT == S_IFMT" es satisfecho. Por lo tanto, se debe aplicar un parche para cambiar el tamaño de la matriz nilfs_type_by_mode para evitar errores OOB. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243 https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8 https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1 https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0 https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611 https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9 https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f •
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: 7.0EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26976 – KVM: Always flush async #PF workqueue when vCPU is being destroyed
https://notcve.org/view.php?id=CVE-2024-26976
In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. • https://git.kernel.org/stable/c/af585b921e5d1e919947c4b1164b59507fe7cd7b https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5 https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264 https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98 https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce • CWE-400: Uncontrolled Resource Consumption •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26973 – fat: fix uninitialized field in nostale filehandles
https://notcve.org/view.php?id=CVE-2024-26973
In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fat: corrige el campo no inicializado en los identificadores de archivos notale Cuando fat_encode_fh_nostale() codifica el identificador de archivo sin un padre, almacena solo los primeros 10 bytes del identificador de archivo. • https://git.kernel.org/stable/c/ea3983ace6b79c96e6ab3d3837e2eaf81ab881e2 https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63 https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6 https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375 https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3 •