CVSS: 4.7EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26656 – drm/amdgpu: fix use-after-free bug
https://notcve.org/view.php?id=CVE-2024-26656
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free bug The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>. For example the following code: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; int ret; arg.addr = 0xffffffffffff0000; arg.size = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg); } Due to the address and size are not valid there is a failure in amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert-> check_shl_overflow, but we even the amdgpu_hmm_register failure we still call amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address. The following stack is below when the issue is reproduced when Kazan is enabled: [ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000 [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [ +0.000010] Call Trace: [ +0.000006] <TASK> [ +0.000007] ? show_regs+0x6a/0x80 [ +0.000018] ? __warn+0xa5/0x1b0 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000018] ? report_bug+0x24a/0x290 [ +0.000022] ? • https://git.kernel.org/stable/c/e87e08c94c9541b4e18c4c13f2f605935f512605 https://git.kernel.org/stable/c/af054a5fb24a144f99895afce9519d709891894c https://git.kernel.org/stable/c/22f665ecfd1225afa1309ace623157d12bb9bb0c https://git.kernel.org/stable/c/22207fd5c80177b860279653d017474b2812af5e https://access.redhat.com/security/cve/CVE-2024-26656 https://bugzilla.redhat.com/show_bug.cgi?id=2272692 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26654 – ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
https://notcve.org/view.php?id=CVE-2024-26654
In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below: (Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | • https://git.kernel.org/stable/c/198de43d758ca2700e2b52b49c0b189b4931466c https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2 https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2 https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845 https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5 https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046 https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901 https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5 •
CVSS: 8.4EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52629 – sh: push-switch: Reorder cleanup operations to avoid use-after-free bug
https://notcve.org/view.php?id=CVE-2023-52629
In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | . • https://git.kernel.org/stable/c/9f5e8eee5cfe1328660c71812d87c2a67bda389f https://git.kernel.org/stable/c/610dbd8ac271aa36080aac50b928d700ee3fe4de https://git.kernel.org/stable/c/246f80a0b17f8f582b2c0996db02998239057c65 • CWE-416: Use After Free •
CVSS: 7.3EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52628 – netfilter: nftables: exthdr: fix 4-byte stack OOB write
https://notcve.org/view.php?id=CVE-2023-52628
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: exthdr: fix 4-byte stack OOB write If priv->len is a multiple of 4, then dst[len / 4] can write past the destination array which leads to stack corruption. This construct is necessary to clean the remainder of the register in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does. The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added. Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: exthdr: corrige escritura OOB de pila de 4 bytes Si priv->len es múltiplo de 4, entonces dst[len / 4] puede escribir más allá de la matriz de destino que conduce a la corrupción de la pila. Esta construcción es necesaria para limpiar el resto del registro en caso de que ->len NO sea un múltiplo del tamaño del registro, así que hágalo condicional tal como lo hace nft_payload.c. El error se agregó en el ciclo 4.1 y luego se copió/heredó cuando se agregó la compatibilidad con las opciones tcp/sctp e ip. Error informado por el proyecto Zero Day Initiative (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961). • https://git.kernel.org/stable/c/49499c3e6e18b7677a63316f3ff54a16533dc28f https://git.kernel.org/stable/c/28a97c43c9e32f437ebb8d6126f9bb7f3ca9521a https://git.kernel.org/stable/c/cf39c4f77a773a547ac2bcf30ecdd303bb0c80cb https://git.kernel.org/stable/c/a7d86a77c33ba1c357a7504341172cc1507f0698 https://git.kernel.org/stable/c/1ad7b189cc1411048434e8595ffcbe7873b71082 https://git.kernel.org/stable/c/d9ebfc0f21377690837ebbd119e679243e0099cc https://git.kernel.org/stable/c/c8f292322ff16b9a2272a67de396c09a50e09dce https://git.kernel.org/stable/c/fd94d9dadee58e09b49075240fe83423e • CWE-787: Out-of-bounds Write •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26652 – net: pds_core: Fix possible double free in error handling path
https://notcve.org/view.php?id=CVE-2024-26652
In the Linux kernel, the following vulnerability has been resolved: net: pds_core: Fix possible double free in error handling path When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), Callback function pdsc_auxbus_dev_release calls kfree(padev) to free memory. We shouldn't call kfree(padev) again in the error handling path. Fix this by cleaning up the redundant kfree() and putting the error handling back to where the errors happened. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: pds_core: corrige posible doble liberación en la ruta de manejo de errores Cuando auxiliar_device_add() devuelve un error y luego llama a auxiliar_device_uninit(), la función de devolución de llamada pdsc_auxbus_dev_release llama a kfree(padev) para liberar memoria. No deberíamos volver a llamar a kfree(padev) en la ruta de manejo de errores. Solucione este problema limpiando el kfree() redundante y devolviendo el manejo de errores al lugar donde ocurrieron los errores. • https://git.kernel.org/stable/c/4569cce43bc61e4cdd76597a1cf9b608846c18cc https://git.kernel.org/stable/c/995f802abff209514ac2ee03b96224237646cec3 https://git.kernel.org/stable/c/ffda0e962f270b3ec937660afd15b685263232d3 https://git.kernel.org/stable/c/ba18deddd6d502da71fd6b6143c53042271b82bd •