CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26619 – riscv: Fix module loading free order
https://notcve.org/view.php?id=CVE-2024-26619
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix module loading free order Reverse order of kfree calls to resolve use-after-free error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige el orden libre de carga del módulo. Orden inverso de las llamadas kfree para resolver el error de use-after-free. • https://git.kernel.org/stable/c/d8792a5734b0f3e58b898c2e2f910bfac48e9ee3 https://git.kernel.org/stable/c/2fa79badf4bfeffda6b5032cf62b828486ec9a99 https://git.kernel.org/stable/c/78996eee79ebdfe8b6f0e54cb6dcc792d5129291 •
CVSS: 6.0EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26618 – arm64/sme: Always exit sme_alloc() early with existing storage
https://notcve.org/view.php?id=CVE-2024-26618
In the Linux kernel, the following vulnerability has been resolved: arm64/sme: Always exit sme_alloc() early with existing storage When sme_alloc() is called with existing storage and we are not flushing we will always allocate new storage, both leaking the existing storage and corrupting the state. Fix this by separating the checks for flushing and for existing storage as we do for SVE. Callers that reallocate (eg, due to changing the vector length) should call sme_free() themselves. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/sme: salir siempre de sme_alloc() antes de tiempo con el almacenamiento existente. Cuando se llama a sme_alloc() con el almacenamiento existente y no estamos vaciando, siempre asignaremos nuevo almacenamiento, y ambos filtrarán el almacenamiento existente, almacenamiento y corrupción del estado. Solucione este problema separando los controles de descarga y de almacenamiento existente como lo hacemos con SVE. • https://git.kernel.org/stable/c/5d0a8d2fba50e9c07cde4aad7fba28c008b07a5b https://git.kernel.org/stable/c/21614ba60883eb93b99a7ee4b41cb927f93b39ae https://git.kernel.org/stable/c/e01af8e26c23a08625a3dd6c8c472a1752d76cce https://git.kernel.org/stable/c/569156e4fa347237f8fa2a7e935d860109c55ac4 https://git.kernel.org/stable/c/814af6b4e6000e574e74d92197190edf07cc3680 https://git.kernel.org/stable/c/dc7eb8755797ed41a0d1b5c0c39df3c8f401b3d9 https://access.redhat.com/security/cve/CVE-2024-26618 https://bugzilla.redhat.com/show_bug.cgi?id=2269192 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26617 – fs/proc/task_mmu: move mmu notification mechanism inside mm lock
https://notcve.org/view.php?id=CVE-2024-26617
In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: move mmu notification mechanism inside mm lock Move mmu notification mechanism inside mm lock to prevent race condition in other components which depend on it. The notifier will invalidate memory range. Depending upon the number of iterations, different memory ranges would be invalidated. The following warning would be removed by this patch: WARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 There is no behavioural and performance change with this patch when there is no component registered with the mmu notifier. [akpm@linux-foundation.org: narrow the scope of `range', per Sean] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc/task_mmu: mover el mecanismo de notificación mmu dentro del bloqueo mm Mueva el mecanismo de notificación mmu dentro del bloqueo mm para evitar condiciones de ejecución en otros componentes que dependen de él. • https://git.kernel.org/stable/c/52526ca7fdb905a768a93f8faa418e9b988fc34b https://git.kernel.org/stable/c/05509adf297924f51e1493aa86f9fcde1433ed80 https://git.kernel.org/stable/c/4cccb6221cae6d020270606b9e52b1678fc8b71a •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26616 – btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned
https://notcve.org/view.php?id=CVE-2024-26616
In the Linux kernel, the following vulnerability has been resolved: btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned [BUG] There is a bug report that, on a ext4-converted btrfs, scrub leads to various problems, including: - "unable to find chunk map" errors BTRFS info (device vdb): scrub: started on devid 1 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056 This would lead to unrepariable errors. - Use-after-free KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0 Read of size 8 at addr ffff8881013c9040 by task btrfs/909 CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023 Call Trace: <TASK> dump_stack_lvl+0x43/0x60 print_report+0xcf/0x640 kasan_report+0xa6/0xd0 __blk_rq_map_sg+0x18f/0x7c0 virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] blk_mq_flush_plug_list.part.0+0x780/0x860 __blk_flush_plug+0x1ba/0x220 blk_finish_plug+0x3b/0x60 submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] __x64_sys_ioctl+0xbd/0x100 do_syscall_64+0x5d/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f47e5e0952b - Crash, mostly due to above use-after-free [CAUSE] The converted fs has the following data chunk layout: item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80 length 86016 owner 2 stripe_len 65536 type DATA|single For above logical bytenr 2214744064, it's at the chunk end (2214658048 + 86016 = 2214744064). This means btrfs_submit_bio() would split the bio, and trigger endio function for both of the two halves. However scrub_submit_initial_read() would only expect the endio function to be called once, not any more. This means the first endio function would already free the bbio::bio, leaving the bvec freed, thus the 2nd endio call would lead to use-after-free. [FIX] - Make sure scrub_read_endio() only updates bits in its range Since we may read less than 64K at the end of the chunk, we should not touch the bits beyond chunk boundary. - Make sure scrub_submit_initial_read() only to read the chunk range This is done by calculating the real number of sectors we need to read, and add sector-by-sector to the bio. Thankfully the scrub read repair path won't need extra fixes: - scrub_stripe_submit_repair_read() With above fixes, we won't update error bit for range beyond chunk, thus scrub_stripe_submit_repair_read() should never submit any read beyond the chunk. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: limpieza: evita el use-after-free cuando la longitud del fragmento no está alineada con 64 K [ERROR] Hay un informe de error que indica que, en un btrfs convertido a ext4, la limpieza conduce a varios problemas, que incluyen: - Errores "no se puede encontrar el mapa de fragmentos" Información BTRFS (dispositivo vdb): limpieza: iniciado en el devid 1 BTRFS crítico (dispositivo vdb): no se puede encontrar el mapa de fragmentos para la longitud lógica 2214744064 4096 BTRFS crítico (dispositivo vdb): No se puede encontrar el mapa de fragmentos para la longitud lógica 2214744064 45056. Esto provocaría errores irreparables. - Informes KASAN de uso gratuito: =========================================== ========================= ERROR: KASAN: slab-use-after-free en __blk_rq_map_sg+0x18f/0x7c0 Lectura de tamaño 8 en la dirección ffff8881013c9040 por tarea btrfs/909 CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 2023.11-2 24/12/2023 Seguimiento de llamadas : dump_stack_lvl+0x43/0x60 print_report+0xcf/0x640 kasan_report+0xa6/0xd0 __blk_rq_map_sg+0x18f/0x7c0 virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02ed fad39bb9ddee07dcdaff] virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] blk_mq_flush_plug_list.part. 0+0x780/0x860 __blk_flush_plug+0x1ba/0x220 blk_finish_plug+0x3b/0x60 submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Flush_scrub_stripes+0x38 e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_chunk+0x178/0x200 [btrfs e579 87a360cama82fe8756dcd3e0de5406ccfe965 ] Scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btr fs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] __x64_sys_ioctl+0xbd/0x100 do_syscall_64+0x5d/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b QEPD: 0033:0x7f47e5e0952b - Fallo , principalmente debido al use-after-free anterior [CAUSA] El fs convertido tiene el siguiente diseño de fragmento de datos: clave del elemento 2 (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 tamaño del elemento 80 longitud 86016 propietario 2 stripe_len 65536 tipo DATOS|single Para el bytenr lógico anterior 2214744064 , está al final del fragmento (2214658048 + 86016 = 2214744064). Esto significa que btrfs_submit_bio() dividiría la biografía y activaría la función endio para ambas mitades. Sin embargo, Scrub_submit_initial_read() solo esperaría que la función endio se llamara una vez, ya no. • https://git.kernel.org/stable/c/e02ee89baa66c40e1002cf8b09141fce7265e0f5 https://git.kernel.org/stable/c/642b9c520ef2f104277ad1f902f8526edbe087fb https://git.kernel.org/stable/c/34de0f04684ec00c093a0455648be055f0e8e24f https://git.kernel.org/stable/c/f546c4282673497a06ecb6190b50ae7f6c85b02f •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26615 – net/smc: fix illegal rmb_desc access in SMC-D connection dump
https://notcve.org/view.php?id=CVE-2024-26615
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL> - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? • https://git.kernel.org/stable/c/4b1b7d3b30a6d32ac1a1dcede284e76ef8a8542d https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22 https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9 https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3e • CWE-476: NULL Pointer Dereference •