CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26988 – init/main.c: Fix potential static_command_line memory overflow
https://notcve.org/view.php?id=CVE-2024-26988
In the Linux kernel, the following vulnerability has been resolved: init/main.c: Fix potential static_command_line memory overflow We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_line are extra_command_line and command_line, rather than extra_command_line and boot_command_line. When strlen(command_line) > strlen(boot_command_line), static_command_line will overflow. This patch just recovers strlen(command_line) which was miss-consolidated with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: init/main.c: soluciona un posible desbordamiento de memoria de static_command_line Asignamos memoria de tamaño 'xlen + strlen(boot_command_line) + 1' para static_command_line, pero las cadenas copiadas en static_command_line son extra_command_line y command_line, en lugar de extra_command_line y boot_command_line. Cuando strlen(command_line) > strlen(boot_command_line), static_command_line se desbordará. Este parche simplemente recupera strlen(command_line) que no se consolidó con strlen(boot_command_line) en el commit f5c7310ac73e ("init/main: agregue comprobaciones para el valor de retorno de memblock_alloc*()") A static_command_line memory overflow was found in the Linux kernel. This issue may cause a crash. • https://git.kernel.org/stable/c/f5c7310ac73ea270e3a1acdb73d1b4817f11fd67 https://git.kernel.org/stable/c/2ef607ea103616aec0289f1b65d103d499fa903a https://git.kernel.org/stable/c/0dc727a4e05400205358a22c3d01ccad2c8e1fe4 https://git.kernel.org/stable/c/76c2f4d426a5358fced5d5990744d46f10a4ccea https://git.kernel.org/stable/c/81cf85ae4f2dd5fa3e43021782aa72c4c85558e8 https://git.kernel.org/stable/c/936a02b5a9630c5beb0353c3085cc49d86c57034 https://git.kernel.org/stable/c/46dad3c1e57897ab9228332f03e1c14798d2d3b9 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26984 – nouveau: fix instmem race condition around ptr stores
https://notcve.org/view.php?id=CVE-2024-26984
In the Linux kernel, the following vulnerability has been resolved: nouveau: fix instmem race condition around ptr stores Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? • https://git.kernel.org/stable/c/be55287aa5ba6895e9d4d3ed2f08a1be7a065957 https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9 https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7 https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716 https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572 https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039 https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525 https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-476: NULL Pointer Dereference •
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 • CWE-125: Out-of-bounds Read •
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: 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 •