CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-27070 – f2fs: fix to avoid use-after-free issue in f2fs_filemap_fault
https://notcve.org/view.php?id=CVE-2024-27070
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free issue in f2fs_filemap_fault syzbot reports a f2fs bug as below: BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058 CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x163/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x170 mm/kasan/report.c:601 f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 __do_fault+0x131/0x450 mm/memory.c:4376 do_shared_fault mm/memory.c:4798 [inline] do_fault mm/memory.c:4872 [inline] do_pte_missing mm/memory.c:3745 [inline] handle_pte_fault mm/memory.c:5144 [inline] __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285 handle_mm_fault+0x27e/0x770 mm/memory.c:5450 do_user_addr_fault arch/x86/mm/fault.c:1364 [inline] handle_page_fault arch/x86/mm/fault.c:1507 [inline] exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 The root cause is: in f2fs_filemap_fault(), vmf->vma may be not alive after filemap_fault(), so it may cause use-after-free issue when accessing vmf->vma->vm_flags in trace_f2fs_filemap_fault(). So it needs to keep vm_flags in separated temporary variable for tracepoint use. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: solución para evitar el problema de use-after-free en f2fs_filemap_fault syzbot informa un error de f2fs como se muestra a continuación: ERROR: KASAN: slab-use-after-free en f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 Lectura de tamaño 8 en la dirección ffff88807bb22680 por tarea syz-executor184/5058 CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 print_address_description mm/kasan/ report.c:377 [en línea] print_report+0x163/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x170 mm/kasan/report.c:601 f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 __do_fault+0x131/0x450 mm/memory.c:4376 do_shared_fault mm/memory.c:4798 [en línea] do_fault mm/memory.c:4872 [en línea] do_pte_missing mm/memory.c:3745 [en línea] handle_pte_fault mm/memory. c:5144 [en línea] __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285 handle_mm_fault+0x27e/0x770 mm/memory.c:5450 do_user_addr_fault arch/x86/mm/fault.c:1364 [en línea] handle_page_fault arch/x86/ mm/fault.c:1507 [en línea] exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 La causa raíz es: en f2fs_filemap_fault(), es posible que vmf->vma no esté activo después de filemap_fault(), por lo que puede causar un problema de use-after-free al acceder a vmf->vma->vm_flags en trace_f2fs_filemap_fault(). Por lo tanto, debe mantener vm_flags en una variable temporal separada para su uso en puntos de seguimiento. • https://git.kernel.org/stable/c/87f3afd366f7c668be0269efda8a89741a3ea6b3 https://git.kernel.org/stable/c/8186e16a766d709a08f188d2f4e84098f364bea1 https://git.kernel.org/stable/c/eb70d5a6c932d9d23f4bb3e7b83782c21ac4b064 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-27069 – ovl: relax WARN_ON in ovl_verify_area()
https://notcve.org/view.php?id=CVE-2024-27069
In the Linux kernel, the following vulnerability has been resolved: ovl: relax WARN_ON in ovl_verify_area() syzbot hit an assertion in copy up data loop which looks like it is the result of a lower file whose size is being changed underneath overlayfs. This type of use case is documented to cause undefined behavior, so returning EIO error for the copy up makes sense, but it should not be causing a WARN_ON assertion. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ovl: relax WARN_ON en ovl_verify_area() syzbot alcanzó una afirmación en el bucle de copia de datos que parece ser el resultado de un archivo inferior cuyo tamaño se está cambiando debajo de overlayfs. Está documentado que este tipo de caso de uso causa un comportamiento indefinido, por lo que devolver un error EIO para la copia tiene sentido, pero no debería causar una afirmación WARN_ON. • https://git.kernel.org/stable/c/ca7ab482401cf0a7497dad05f4918dc64115538b https://git.kernel.org/stable/c/c3c85aefc0da1e5074a06c682542a54ccc99bdca https://git.kernel.org/stable/c/77a28aa476873048024ad56daf8f4f17d58ee48e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27068 – thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path
https://notcve.org/view.php?id=CVE-2024-27068
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path If devm_krealloc() fails, then 'efuse' is leaking. So free it to avoid a leak. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/drivers/mediatek/lvts_thermal: corrige una pérdida de memoria en una ruta de manejo de errores. Si devm_krealloc() falla, entonces 'efuse' tiene una fuga. Así que libérelo para evitar una fuga. • https://git.kernel.org/stable/c/f5f633b18234cecb0e6ee6e5fbb358807dda15c3 https://git.kernel.org/stable/c/2db869da91afd48e5b9ec76814709be49662b07d https://git.kernel.org/stable/c/a37f3652bee468f879d35fe2da9ede3f1dcbb7be https://git.kernel.org/stable/c/9b02197596671800dd934609384b1aca7c6ad218 https://git.kernel.org/stable/c/ca93bf607a44c1f009283dac4af7df0d9ae5e357 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27067 – xen/evtchn: avoid WARN() when unbinding an event channel
https://notcve.org/view.php?id=CVE-2024-27067
In the Linux kernel, the following vulnerability has been resolved: xen/evtchn: avoid WARN() when unbinding an event channel When unbinding a user event channel, the related handler might be called a last time in case the kernel was built with CONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler. Avoid that by adding an "unbinding" flag to struct user_event which will short circuit the handler. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xen/evtchn: evite WARN() al desvincular un canal de eventos Al desvincular un canal de eventos de usuario, es posible que se llame al controlador relacionado por última vez en caso de que el kernel se haya compilado con CONFIG_DEBUG_SHIRQ. Esto podría provocar un WARN() en el controlador. Evite esto agregando un indicador de "desvinculación" a la estructura user_event que provocará un cortocircuito en el controlador. • https://git.kernel.org/stable/c/3c8f5965a99397368d3762a9814a21a3e442e1a4 https://git.kernel.org/stable/c/9e90e58c11b74c2bddac4b2702cf79d36b981278 https://git.kernel.org/stable/c/99e425032c6ec13584d3cd33846e0c7307501b47 https://git.kernel.org/stable/c/35485dad6e28f9b17884764d4692b1655cb848d0 https://git.kernel.org/stable/c/9e2d4b58c1da48a32905802aaeadba7084b46895 https://git.kernel.org/stable/c/51c23bd691c0f1fb95b29731c356c6fd69925d17 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27066 – virtio: packed: fix unmap leak for indirect desc table
https://notcve.org/view.php?id=CVE-2024-27066
In the Linux kernel, the following vulnerability has been resolved: virtio: packed: fix unmap leak for indirect desc table When use_dma_api and premapped are true, then the do_unmap is false. Because the do_unmap is false, vring_unmap_extra_packed is not called by detach_buf_packed. if (unlikely(vq->do_unmap)) { curr = id; for (i = 0; i < state->num; i++) { vring_unmap_extra_packed(vq, &vq->packed.desc_extra[curr]); curr = vq->packed.desc_extra[curr].next; } } So the indirect desc table is not unmapped. This causes the unmap leak. So here, we check vq->use_dma_api instead. Synchronously, dma info is updated based on use_dma_api judgment This bug does not occur, because no driver use the premapped with indirect. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio: empaquetado: corrige la fuga de desasignación para la tabla desc indirecta Cuando use_dma_api y premapped son verdaderos, entonces do_unmap es falso. Debido a que do_unmap es falso, detach_buf_packed no llama a vring_unmap_extra_packed. if (improbable(vq->do_unmap)) { curr = id; for (i = 0; i < estado->num; i++) { vring_unmap_extra_packed(vq, &vq->packed.desc_extra[curr]); curr = vq->packed.desc_extra[curr].next; } } Por lo tanto, la tabla de descripción indirecta no está desasignada. • https://git.kernel.org/stable/c/b319940f83c21bb4c1fabffe68a862be879a6193 https://git.kernel.org/stable/c/e142169aca5546ae6619c39a575cda8105362100 https://git.kernel.org/stable/c/75450ff8c6fe8755bf5b139b238eaf9739cfd64e https://git.kernel.org/stable/c/51bacd9d29bf98c3ebc65e4a0477bb86306b4140 https://git.kernel.org/stable/c/d5c0ed17fea60cca9bc3bf1278b49ba79242bbcd •