CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50114 – KVM: arm64: Unregister redistributor for failed vCPU creation
https://notcve.org/view.php?id=CVE-2024-50114
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Unregister redistributor for failed vCPU creation Alex reports that syzkaller has managed to trigger a use-after-free when tearing down a VM: BUG: KASAN: slab-use-after-free in kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 Read of size 8 at addr ffffff801c6890d0 by task syz.3.2219/10758 CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 Not tainted 6.11.0-rc6-dirty #64 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324 __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119 print_report+0x144/0x7a4 mm/kasan/report.c:377 kasan_report+0xcc/0x128 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409 __fput+0x198/0x71c fs/file_table.c:422 ____fput+0x20/0x30 fs/file_table.c:450 task_work_run+0x1cc/0x23c kernel/task_work.c:228 do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50 el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Upon closer inspection, it appears that we do not properly tear down the MMIO registration for a vCPU that fails creation late in the game, e.g. a vCPU w/ the same ID already exists in the VM. It is important to consider the context of commit that introduced this bug by moving the unregistration out of __kvm_vgic_vcpu_destroy(). That change correctly sought to avoid an srcu v. config_lock inversion by breaking up the vCPU teardown into two parts, one guarded by the config_lock. Fix the use-after-free while avoiding lock inversion by adding a special-cased unregistration to __kvm_vgic_vcpu_destroy(). This is safe because failed vCPUs are torn down outside of the config_lock. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Anular el registro del redistribuidor en caso de creación fallida de una vCPU. Alex informa que syzkaller ha conseguido activar un use-after-free al desmantelar una máquina virtual: ERROR: KASAN: slab-use-after-free en kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 Lectura de tamaño 8 en la dirección ffffff801c6890d0 por la tarea syz.3.2219/10758 CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 No contaminado 6.11.0-rc6-dirty #64 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324 __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119 print_report+0x144/0x7a4 mm/kasan/report.c:377 kasan_report+0xcc/0x128 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409 __fput+0x198/0x71c fs/file_table.c:422 ____fput+0x20/0x30 fs/file_table.c:450 task_work_run+0x1cc/0x23c kernel/task_work.c:228 do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50 el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Tras una inspección más detallada, parece que no eliminamos correctamente el registro MMIO para una vCPU que falla en la creación tarde en el juego, por ejemplo, una vCPU con el mismo ID ya existe en la VM. • https://git.kernel.org/stable/c/f616506754d34bcfdbfbc7508b562e5c98461e9a https://git.kernel.org/stable/c/6bcc2890b883ba1d16b8942937750565f6e9db0d https://git.kernel.org/stable/c/ae8f8b37610269009326f4318df161206c59843e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50113 – firewire: core: fix invalid port index for parent device
https://notcve.org/view.php?id=CVE-2024-50113
In the Linux kernel, the following vulnerability has been resolved: firewire: core: fix invalid port index for parent device In a commit 24b7f8e5cd65 ("firewire: core: use helper functions for self ID sequence"), the enumeration over self ID sequence was refactored with some helper functions with KUnit tests. These helper functions are guaranteed to work expectedly by the KUnit tests, however their application includes a mistake to assign invalid value to the index of port connected to parent device. This bug affects the case that any extra node devices which has three or more ports are connected to 1394 OHCI controller. In the case, the path to update the tree cache could hits WARN_ON(), and gets general protection fault due to the access to invalid address computed by the invalid value. This commit fixes the bug to assign correct port index. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firewire: core: fix invalid port index for parent device En una confirmación 24b7f8e5cd65 ("firewire: core: use helper functions for self ID sequence"), la enumeración sobre la secuencia de auto-identificación se refactorizó con algunas funciones auxiliares con pruebas KUnit. Se garantiza que estas funciones auxiliares funcionarán como se espera mediante las pruebas KUnit, sin embargo, su aplicación incluye un error para asignar un valor no válido al índice del puerto conectado al dispositivo principal. • https://git.kernel.org/stable/c/24b7f8e5cd656196a13077e160aec45ad89b58d9 https://git.kernel.org/stable/c/90753a38bc3d058820981f812a908a99f7b337c1 https://git.kernel.org/stable/c/f6a6780e0b9bbcf311a727afed06fee533a5e957 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50112 – x86/lam: Disable ADDRESS_MASKING in most cases
https://notcve.org/view.php?id=CVE-2024-50112
In the Linux kernel, the following vulnerability has been resolved: x86/lam: Disable ADDRESS_MASKING in most cases Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in market that support LAM yet, so currently nobody is affected by this issue. [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ [ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/lam: Deshabilitar ADDRESS_MASKING en la mayoría de los casos. El enmascaramiento de direcciones lineales (LAM) tiene una debilidad relacionada con la ejecución transitoria como se describe en el documento SLAM[1]. A menos que se habilite la separación del espacio de direcciones lineales (LASS), esta debilidad puede ser explotable. Hasta que el kernel agregue soporte para LASS[2], solo permita LAM para COMPILE_TEST, o cuando las mitigaciones de especulación se hayan deshabilitado en el momento de la compilación, de lo contrario, mantenga LAM deshabilitado. • https://git.kernel.org/stable/c/60a5ba560f296ad8da153f6ad3f70030bfa3958f https://git.kernel.org/stable/c/690599066488d16db96ac0d6340f9372fc56f337 https://git.kernel.org/stable/c/3267cb6d3a174ff83d6287dcd5b0047bbd912452 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50111 – LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context
https://notcve.org/view.php?id=CVE-2024-50111
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context Unaligned access exception can be triggered in irq-enabled context such as user mode, in this case do_ale() may call get_user() which may cause sleep. Then we will get: BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G W 6.12.0-rc1+ #1723 Tainted: [W]=WARN Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 000000000000020c 000000000000000a 0000000000000000 0000000000000003 00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260 0000000000000000 0000000000000000 9000000005437650 90000000055d5000 0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000 0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec 00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d ... Call Trace: [<9000000003803964>] show_stack+0x64/0x1a0 [<9000000004c57464>] dump_stack_lvl+0x74/0xb0 [<9000000003861ab4>] __might_resched+0x154/0x1a0 [<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60 [<9000000004c58118>] do_ale+0x78/0x180 [<9000000003801bc8>] handle_ale+0x128/0x1e0 So enable IRQ if unaligned access exception is triggered in irq-enabled context to fix it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Habilitar IRQ si do_ale() se activa en un contexto habilitado para irq. La excepción de acceso no alineado se puede activar en un contexto habilitado para irq, como el modo de usuario; en este caso, do_ale() puede llamar a get_user(), lo que puede provocar una suspensión. Entonces obtendremos: ERROR: función inactiva llamada desde un contexto no válido en arch/loongarch/kernel/access-helper.h:7 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, nombre: modprobe preempt_count: 0, esperado: 0 Profundidad de anidación de RCU: 0, esperado: 0 CPU: 0 UID: 0 PID: 129 Comm: modprobe Contaminado: GW 6.12.0-rc1+ #1723 Contaminado: [W]=WARN Pila: 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 9000000105e0bc70 9000000105e0bc78 000000000000000 0000000000000000 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 000000000000020c 00000000000000a 0000000000000000 000000000000003 000000000000023f0 000000000000e1401 00000000072f8000 0000007ffbb0e260 0000000000000000 000000000000000 9000000005437650 90000000055d5000 0000000000000000 0000000000000003 0000007ffbb0e1f0 000000000000000 000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec 000000000000000b0 0000000000000007 0000000000000003 0000000000071c1d ... • https://git.kernel.org/stable/c/8915ed160dbd32b5ef5864df9a9fc11db83a77bb https://git.kernel.org/stable/c/afbfb3568d78082078acc8bb2b29bb47af87253c https://git.kernel.org/stable/c/69cc6fad5df4ce652d969be69acc60e269e5eea1 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50110 – xfrm: fix one more kernel-infoleak in algo dumping
https://notcve.org/view.php?id=CVE-2024-50110
In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae ("xfrm: Zero padding when dumping algos and encap") Found by Linux Verification Center (linuxtesting.org) with Syzkaller. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: corrige una fuga de información del kernel más en el volcado de algoritmos. Durante las pruebas fuzz, se descubrió el siguiente problema: ERROR: KMSAN: fuga de información del kernel en _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Ununit se almacenó en la memoria en: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit se creó en: __kmalloc+0x571/0xd30 attached_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Los bytes 328-379 de 732 no están inicializados El acceso a la memoria de tamaño 732 comienza en ffff88800e18e000 Datos copiados a la dirección de usuario 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 No contaminado 6.8.11 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Corrige la copia de algoritmos xfrm donde algunos datos aleatorios de los campos de estructura pueden terminar en el espacio de usuario. El relleno en las estructuras se puede rellenar con datos aleatorios (posiblemente confidenciales) y nunca se debe proporcionar directamente al espacio de usuario. Un problema similar se resolvió en la confirmación 8222d5910dae ("xfrm: relleno de ceros al volcar algoritmos y encap") encontrado por Linux Verification Center (linuxtesting.org) con Syzkaller. • https://git.kernel.org/stable/c/c7a5899eb26e2a4d516d53f65b6dd67be2228041 https://git.kernel.org/stable/c/610d4cea9b442b22b4820695fc3335e64849725e https://git.kernel.org/stable/c/dc2ad8e8818e4bf1a93db78d81745b4877b32972 https://git.kernel.org/stable/c/c73bca72b84b453c8d26a5e7673b20adb294bf54 https://git.kernel.org/stable/c/1e8fbd2441cb2ea28d6825f2985bf7d84af060bb https://git.kernel.org/stable/c/6889cd2a93e1e3606b3f6e958aa0924e836de4d2 •