CVSS: 6.2EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36910 – uio_hv_generic: Don't free decrypted memory
https://notcve.org/view.php?id=CVE-2024-36910
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus device UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uio_hv_generic: no liberar memoria descifrada. En las máquinas virtuales CoCo, es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle, de modo que se devuelva un error y el resultado La memoria es compartida. • https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54 https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9 https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23 https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36909 – Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted
https://notcve.org/view.php?id=CVE-2024-36909
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus ring buffer code could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the struct vmbus_gpadl for the ring buffers to decide whether to free the memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: no liberar búferes de anillo que no se pudieron volver a cifrar. En las máquinas virtuales CoCo, es posible que el host que no es de confianza cause set_memory_encrypted() o set_memory_decrypted( ) falle de modo que se devuelva un error y se comparta la memoria resultante. • https://git.kernel.org/stable/c/2f622008bf784a9f5dd17baa19223cc2ac30a039 https://git.kernel.org/stable/c/82f9e213b124a7d2bb5b16ea35d570260ef467e0 https://git.kernel.org/stable/c/a9212a4e2963a7fbe3864ba33dc551d4ad8d0abb https://git.kernel.org/stable/c/30d18df6567be09c1433e81993e35e3da573ac48 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36908 – blk-iocost: do not WARN if iocg was already offlined
https://notcve.org/view.php?id=CVE-2024-36908
In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-iocost: no ADVERTIR si iocg ya estaba desconectado. En iocg_pay_debt(), se activa una advertencia si 'active_list' está vacía, lo que pretende confirmar que iocg está activo cuando deuda. • https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67 https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36907 – SUNRPC: add a missing rpc_stat for TCP TLS
https://notcve.org/view.php?id=CVE-2024-36907
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: add a missing rpc_stat for TCP TLS Commit 1548036ef120 ("nfs: make the rpc_stat per net namespace") added functionality to specify rpc_stats function but missed adding it to the TCP TLS functionality. As the result, mounting with xprtsec=tls lead to the following kernel oops. [ 128.984192] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001c [ 128.985058] Mem abort info: [ 128.985372] ESR = 0x0000000096000004 [ 128.985709] EC = 0x25: DABT (current EL), IL = 32 bits [ 128.986176] SET = 0, FnV = 0 [ 128.986521] EA = 0, S1PTW = 0 [ 128.986804] FSC = 0x04: level 0 translation fault [ 128.987229] Data abort info: [ 128.987597] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 128.988169] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 128.988811] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 128.989302] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000106c84000 [ 128.990048] [000000000000001c] pgd=0000000000000000, p4d=0000000000000000 [ 128.990736] Internal error: Oops: 0000000096000004 [#1] SMP [ 128.991168] Modules linked in: nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace netfs uinput dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink qrtr vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common mc vmw_vmci xfs libcrc32c e1000e crct10dif_ce ghash_ce sha2_ce vmwgfx nvme sha256_arm64 nvme_core sr_mod cdrom sha1_ce drm_ttm_helper ttm drm_kms_helper drm sg fuse [ 128.996466] CPU: 0 PID: 179 Comm: kworker/u4:26 Kdump: loaded Not tainted 6.8.0-rc6+ #12 [ 128.997226] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.21805430.BA64.2305221830 05/22/2023 [ 128.998084] Workqueue: xprtiod xs_tcp_tls_setup_socket [sunrpc] [ 128.998701] pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 128.999384] pc : call_start+0x74/0x138 [sunrpc] [ 128.999809] lr : __rpc_execute+0xb8/0x3e0 [sunrpc] [ 129.000244] sp : ffff8000832b3a00 [ 129.000508] x29: ffff8000832b3a00 x28: ffff800081ac79c0 x27: ffff800081ac7000 [ 129.001111] x26: 0000000004248060 x25: 0000000000000000 x24: ffff800081596008 [ 129.001757] x23: ffff80007b087240 x22: ffff00009a509d30 x21: 0000000000000000 [ 129.002345] x20: ffff000090075600 x19: ffff00009a509d00 x18: ffffffffffffffff [ 129.002912] x17: 733d4d4554535953 x16: 42555300312d746e x15: ffff8000832b3a88 [ 129.003464] x14: ffffffffffffffff x13: ffff8000832b3a7d x12: 0000000000000008 [ 129.004021] x11: 0101010101010101 x10: ffff8000150cb560 x9 : ffff80007b087c00 [ 129.004577] x8 : ffff00009a509de0 x7 : 0000000000000000 x6 : 00000000be8c4ee3 [ 129.005026] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff000094d56680 [ 129.005425] x2 : ffff80007b0637f8 x1 : ffff000090075600 x0 : ffff00009a509d00 [ 129.005824] Call trace: [ 129.005967] call_start+0x74/0x138 [sunrpc] [ 129.006233] __rpc_execute+0xb8/0x3e0 [sunrpc] [ 129.006506] rpc_execute+0x160/0x1d8 [sunrpc] [ 129.006778] rpc_run_task+0x148/0x1f8 [sunrpc] [ 129.007204] tls_probe+0x80/0xd0 [sunrpc] [ 129.007460] rpc_ping+0x28/0x80 [sunrpc] [ 129.007715] rpc_create_xprt+0x134/0x1a0 [sunrpc] [ 129.007999] rpc_create+0x128/0x2a0 [sunrpc] [ 129.008264] xs_tcp_tls_setup_socket+0xdc/0x508 [sunrpc] [ 129.008583] process_one_work+0x174/0x3c8 [ 129.008813] worker_thread+0x2c8/0x3e0 [ 129.009033] kthread+0x100/0x110 [ 129.009225] ret_from_fork+0x10/0x20 [ 129.009432] Code: f0ffffc2 911fe042 aa1403e1 aa1303e0 (b9401c83) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: agrega un rpc_stat faltante para TCP TLS. El commit 1548036ef120 ("nfs: crea rpc_stat por espacio de nombres de red") agregó funcionalidad para especificar la función rpc_stats pero no la agregó a la funcionalidad TCP TLS. . Como resultado, montar con xprtsec=tls conduce a los siguientes errores del kernel. [128.984192] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 000000000000001c [128.985058] Información de cancelación de memoria: [128.985372] ESR = 0x0000000096000004 [128.985709] EC = 0x25: (EL actual), IL = 32 bits [ 128.986176] SET = 0 , FnV = 0 [ 128.986521] EA = 0, S1PTW = 0 [ 128.986804] FSC = 0x04: error de traducción de nivel 0 [ 128.987229] Información de cancelación de datos: [ 128.987597] ISV = 0, ISS = 0x00000004, ISS2 = 0x000 00000 [ 128.988169] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 128.988811] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 128.989302] tabla de páginas de usuario: páginas de 4k, VA de 48 bits, pgdp=0000000106c84000 [ 128.990048] [000000000000001c] pgd=0000000000000000, p4d=0000000000000000 [ 128.990736] Error interno: Ups: 0000000096000004 [#1] SMP [ 168] Módulos vinculados en: nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd Grace netfs uinput dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf _rechazar_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink qrtr vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock pc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common mc vmw_vmci xfs libcrc32c e1000e crct10dif_ce ghash_ce sha2_ce vmwgfx nvme sha256_arm64 nvme_core sr_mod cdrom sha1_ce _ttm_helper ttm drm_kms_helper drm sg fusible [ 128.996466 ] CPU: 0 PID: 179 Comm: kworker/u4:26 Kdump: cargado No contaminado 6.8.0-rc6+ #12 [ 128.997226] Nombre de hardware: VMware, Inc. • https://git.kernel.org/stable/c/19f51adc778fb84c2eb07eb71800fb0d9f0ff13a https://git.kernel.org/stable/c/afdbc21a92a0cdc497d8879aeff7b284094fae02 https://git.kernel.org/stable/c/7ceb89f4016ea6ed3e59b015d4200739d45c790e https://git.kernel.org/stable/c/2b7f2d663a965943e8820b6a40cc2abe2eee7431 https://git.kernel.org/stable/c/9b332c72299f2ac284ab3d7c0301969b933e4ca1 https://git.kernel.org/stable/c/024f7744bd09cb2a47a0a96b9c8ad08109de99cc https://git.kernel.org/stable/c/8e088a20dbe33919695a8082c0b32deb62d23b4a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36906 – ARM: 9381/1: kasan: clear stale stack poison
https://notcve.org/view.php?id=CVE-2024-36906
In the Linux kernel, the following vulnerability has been resolved: ARM: 9381/1: kasan: clear stale stack poison We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9381/1: kasan: borrar veneno de pila obsoleta Encontramos el siguiente fallo de OOB: [33.452494] ================== =================================================== [ 33.453513] ERROR: KASAN: pila fuera de los límites en refresco_cpu_vm_stats.constprop.0+0xcc/0x2ec [33.454660] Escritura de tamaño 164 en la dirección c1d03d30 mediante task swapper/0/0 [33.455515] [33.455767] CPU: 0 PID : 0 Comm: swapper/0 Tainted: GO 6.1.25-mainline #1 [ 33.456880] Nombre del hardware: Sistema basado en DT genérico [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.45 9072] dump_stack_lvl de print_report+0x158/0x4a4 [ 33.459863] print_report de kasan_report+0x9c/0x148 [ 33.460616] kasan_report de kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range de memset+0x20/0x 3c [33.462157] conjunto de memorias de refresco_cpu_vm_stats.constprop.0+0xcc/ 0x2ec [33.463064] refresco_cpu_vm_stats.constprop.0 de tick_nohz_idle_stop_tick+0x180/0x53c [33.464181] tick_nohz_idle_stop_tick de do_idle+0x264/0x354 [33.465029] do_idle de cpu_startup _entry+0x20/0x24 [ 33.465769] cpu_startup_entry de rest_init+0xf0/0xf4 [ 33.466528] rest_init de arch_post_acpi_subsys_init+0x0/0x18 [33.467397] [33.467644] La dirección con errores pertenece a la pila de task swapper/0/0 [33.468493] y se encuentra en el desplazamiento 112 en el framework: [33.469172] [ 33.469917 ] [ 33.470165] Este framework tiene 2 objetos: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] La dirección con errores pertenece a la página física: [ 33.47 2862] página:3cd72da8 refcount:1 mapcount:0 mapeo:00000000 índice:0x0 pfn:0x41d03 [ 33.473944] banderas: 0x1000(reservado|zona=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 000000 00000000 ffffffff 00000001 [ 33.475656] sin formato: 00000000 [33.476050] página volcada porque: kasan: mal acceso detectado [33.476816] [33.477061] Estado de la memoria alrededor de la dirección con errores: [33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 [33.478630] c1d03c80 : 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 3.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] === ==================================================== ==== Descubrimos que la causa principal de este OOB es que el brazo no elimina el veneno de la pila obsoleta en el caso de cpuidle. Este parche hace referencia a arch/arm64/kernel/sleep.S para resolver este problema. Del compromiso citado [1] que explica el problema. Las funciones que el compilador ha instrumentado para KASAN colocan veneno en la sombra de la pila al ingresar y eliminan este veneno antes de regresar. • https://git.kernel.org/stable/c/5615f69bc2097452ecc954f5264d784e158d6801 https://git.kernel.org/stable/c/20ac71bee028ffbae4fc14ed679b23b4d3e95726 https://git.kernel.org/stable/c/ad702338fe423cb1e79745787090317256a98dab https://git.kernel.org/stable/c/ee0ce7573e5083031960faf602c9db693ab5b477 https://git.kernel.org/stable/c/b26f353786d365e658cebc9a9ace88e04fc2325e https://git.kernel.org/stable/c/c4238686f9093b98bd6245a348bcf059cdce23af •