CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47346 – coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()
https://notcve.org/view.php?id=CVE-2021-47346
In the Linux kernel, the following vulnerability has been resolved: coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer() commit 6f755e85c332 ("coresight: Add helper for inserting synchronization packets") removed trailing '\0' from barrier_pkt array and updated the call sites like etb_update_buffer() to have proper checks for barrier_pkt size before read but missed updating tmc_update_etf_buffer() which still reads barrier_pkt past the array size resulting in KASAN out-of-bounds bug. Fix this by adding a check for barrier_pkt size before accessing like it is done in etb_update_buffer(). BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698 Read of size 4 at addr ffffffd05b7d1030 by task perf/2629 Call trace: dump_backtrace+0x0/0x27c show_stack+0x20/0x2c dump_stack+0x11c/0x188 print_address_description+0x3c/0x4a4 __kasan_report+0x140/0x164 kasan_report+0x10/0x18 __asan_report_load4_noabort+0x1c/0x24 tmc_update_etf_buffer+0x4b8/0x698 etm_event_stop+0x248/0x2d8 etm_event_del+0x20/0x2c event_sched_out+0x214/0x6f0 group_sched_out+0xd0/0x270 ctx_sched_out+0x2ec/0x518 __perf_event_task_sched_out+0x4fc/0xe6c __schedule+0x1094/0x16a0 preempt_schedule_irq+0x88/0x170 arm64_preempt_schedule_irq+0xf0/0x18c el1_irq+0xe8/0x180 perf_event_exec+0x4d8/0x56c setup_new_exec+0x204/0x400 load_elf_binary+0x72c/0x18c0 search_binary_handler+0x13c/0x420 load_script+0x500/0x6c4 search_binary_handler+0x13c/0x420 exec_binprm+0x118/0x654 __do_execve_file+0x77c/0xba4 __arm64_compat_sys_execve+0x98/0xac el0_svc_common+0x1f8/0x5e0 el0_svc_compat_handler+0x84/0xb0 el0_svc_compat+0x10/0x50 The buggy address belongs to the variable: barrier_pkt+0x10/0x40 Memory state around the buggy address: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ================================================================== En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: tmc-etf: Corrección global fuera de los límites en tmc_update_etf_buffer() confirmación 6f755e85c332 ("coresight: Agregar ayuda para insertar paquetes de sincronización") eliminado el final '\0' desde la matriz barrier_pkt y actualicé los sitios de llamadas como etb_update_buffer() para realizar comprobaciones adecuadas del tamaño de la barrera_pkt antes de leer, pero no se actualizó tmc_update_etf_buffer(), que todavía lee barrier_pkt más allá del tamaño de la matriz, lo que genera un error de KASAN fuera de los límites. Solucione este problema agregando una verificación del tamaño de barrier_pkt antes de acceder, como se hace en etb_update_buffer(). bug: KASAN: global fuera de los límites en tmc_update_etf_buffer+0x4b8/0x698 Lectura de tamaño 4 en la dirección ffffffd05b7d1030 por tarea perf/2629 Rastreo de llamadas: dump_backtrace+0x0/0x27c show_stack+0x20/0x2c dump_stack+0x11c/0x188 descripción+0x3c /0x4a4 __kasan_report+0x140/0x164 kasan_report+0x10/0x18 __asan_report_load4_noabort+0x1c/0x24 tmc_update_etf_buffer+0x4b8/0x698 etm_event_stop+0x248/0x2d8 etm_event_del+0x20/0x2c event_sched_out+0x214/0x6f0 group_sched_out+0xd0/0x270 ctx_sched_out+0x2ec/0x518 __perf_event_task_sched_out+0x4fc /0xe6c __schedule+0x1094/0x16a0 preempt_schedule_irq+0x88/0x170 arm64_preempt_schedule_irq+0xf0/0x18c el1_irq+0xe8/0x180 perf_event_exec+0x4d8/0x56c setup_new_exec+0x204/0x4 00 load_elf_binary+0x72c/0x18c0 search_binary_handler+0x13c/0x420 load_script+0x500/0x6c4 search_binary_handler+0x13c /0x420 exec_binprm+0x118/0x654 __do_execve_file+0x77c/0xba4 __arm64_compat_sys_execve+0x98/0xac el0_svc_common+0x1f8/0x5e0 el0_svc_compat_handler+0x84/0xb0 x10/0x50 La dirección del buggy pertenece a la variable: barrier_pkt+0x10/0x40 Estado de la memoria alrededor del buggy dirección: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 0 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ====== ==================================================== ========== • https://git.kernel.org/stable/c/0c3fc4d5fa26092853278145aca9b21fa52a3e93 https://git.kernel.org/stable/c/04bd77ef4f4d9fc6102023b85f4590fc2130aac5 https://git.kernel.org/stable/c/ef0a06acc6b16388640ad367eedfa2a17f1945db https://git.kernel.org/stable/c/35c1c4bd2d59ad734129d4e232af9d1098023918 https://git.kernel.org/stable/c/733d4d95c0101d5f277b8e4910411d016e49a9dc https://git.kernel.org/stable/c/0115687be7b13993066aef602253a53d55f5b11f https://git.kernel.org/stable/c/5fae8a946ac2df879caf3f79a193d4766d00239b •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47345 – RDMA/cma: Fix rdma_resolve_route() memory leak
https://notcve.org/view.php?id=CVE-2021-47345
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix rdma_resolve_route() memory leak Fix a memory leak when "mda_resolve_route() is called more than once on the same "rdma_cm_id". This is possible if cma_query_handler() triggers the RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and allows rdma_resolve_route() to be called again. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: Reparar pérdida de memoria rdma_resolve_route(). Reparar una pérdida de memoria cuando se llama a "mda_resolve_route() más de una vez en el mismo "rdma_cm_id". Esto es posible si cma_query_handler() desencadena el flujo RDMA_CM_EVENT_ROUTE_ERROR que devuelve la máquina de estado y permite volver a llamar a rdma_resolve_route(). • https://git.kernel.org/stable/c/40b613db3a95bc27998e4097d74c2f7e5d083a0b https://git.kernel.org/stable/c/e2da8ce2a9543f3ca5c93369bd1fe6eeb572101a https://git.kernel.org/stable/c/e4e062da082a199357ba4911145f331d40139ad8 https://git.kernel.org/stable/c/4893c938f2a140a74be91779e45e4a7fa111198f https://git.kernel.org/stable/c/032c68b4f5be128a2167f35b558b7cec88fe4972 https://git.kernel.org/stable/c/3d08b5917984f737f32d5bee9737b9075c3895c6 https://git.kernel.org/stable/c/f4f553d67236145fa5fd203ed7b35b9377e19939 https://git.kernel.org/stable/c/07583ba2e2d8947c3d365d97608cb4365 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47344 – media: zr364xx: fix memory leak in zr364xx_start_readpipe
https://notcve.org/view.php?id=CVE-2021-47344
In the Linux kernel, the following vulnerability has been resolved: media: zr364xx: fix memory leak in zr364xx_start_readpipe syzbot reported memory leak in zr364xx driver. The problem was in non-freed urb in case of usb_submit_urb() fail. backtrace: [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline] [<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline] [<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516 [<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: zr364xx: corrige la pérdida de memoria en zr364xx_start_readpipe syzbot informó una pérdida de memoria en el controlador zr364xx. El problema estaba en la urb no liberada en caso de que fallara usb_submit_urb(). seguimiento: [] kmalloc include/linux/slab.h:561 [en línea] [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [] zr364xx_start_readpipe+0x78/ 0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [en línea] [] 0x851 drivers/media/ usb/zr364xx/zr364xx.c:1516 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 []really_probe+0x159/0x500 controladores/base/dd.c:576 • https://git.kernel.org/stable/c/ccbf035ae5de4c535160fc99f73feb44cc55b534 https://git.kernel.org/stable/c/c57b2bd3247925e253729dce283d6bf6abc9339d https://git.kernel.org/stable/c/bbc80a972a3c5d7eba3f6c9c07af8fea42f5c513 https://git.kernel.org/stable/c/b0633051a6cb24186ff04ce1af99c7de18c1987e https://git.kernel.org/stable/c/021c294dff030f3ba38eb81e400ba123db32ecbc https://git.kernel.org/stable/c/0edd6759167295ea9969e89283b81017b4c688aa https://git.kernel.org/stable/c/c57bfd8000d7677bf435873b440eec0c47f73a08 https://git.kernel.org/stable/c/5f3f81f1c96b501d180021c23c25e9f48 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47343 – dm btree remove: assign new_root only when removal succeeds
https://notcve.org/view.php?id=CVE-2021-47343
In the Linux kernel, the following vulnerability has been resolved: dm btree remove: assign new_root only when removal succeeds remove_raw() in dm_btree_remove() may fail due to IO read error (e.g. read the content of origin block fails during shadowing), and the value of shadow_spine::root is uninitialized, but the uninitialized value is still assign to new_root in the end of dm_btree_remove(). For dm-thin, the value of pmd->details_root or pmd->root will become an uninitialized value, so if trying to read details_info tree again out-of-bound memory may occur as showed below: general protection fault, probably for non-canonical address 0x3fdcb14c8d7520 CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6 Hardware name: QEMU Standard PC RIP: 0010:metadata_ll_load_ie+0x14/0x30 Call Trace: sm_metadata_count_is_more_than_one+0xb9/0xe0 dm_tm_shadow_block+0x52/0x1c0 shadow_step+0x59/0xf0 remove_raw+0xb2/0x170 dm_btree_remove+0xf4/0x1c0 dm_pool_delete_thin_device+0xc3/0x140 pool_message+0x218/0x2b0 target_message+0x251/0x290 ctl_ioctl+0x1c4/0x4d0 dm_ctl_ioctl+0xe/0x20 __x64_sys_ioctl+0x7b/0xb0 do_syscall_64+0x40/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixing it by only assign new_root when removal succeeds En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm btree remove: asigna new_root solo cuando la eliminación se realiza correctamente. remove_raw() en dm_btree_remove() puede fallar debido a un error de lectura de E/S (por ejemplo, la lectura del contenido del bloque de origen falla durante el sombreado), y el valor de shadow_spine::root no está inicializado, pero el valor no inicializado aún se asigna a new_root al final de dm_btree_remove(). Para dm-thin, el valor de pmd->details_root o pmd->root se convertirá en un valor no inicializado, por lo que si intenta leer el árbol de detalles_info nuevamente, puede ocurrir que la memoria esté fuera de los límites, como se muestra a continuación: falla de protección general, probablemente para no usuarios. -dirección canónica 0x3fdcb14c8d7520 CPU: 4 PID: 515 Comm: dmsetup No contaminado 5.13.0-rc6 Nombre de hardware: QEMU PC estándar RIP: 0010:metadata_ll_load_ie+0x14/0x30 Seguimiento de llamadas: sm_metadata_count_is_more_than_one+0xb9/0xe0 m_shadow_block+0x52/0x1c0 sombra_paso+ 0x59/0xf0 remove_raw+0xb2/0x170 dm_btree_remove+0xf4/0x1c0 dm_pool_delete_thin_device+0xc3/0x140 pool_message+0x218/0x2b0 target_message+0x251/0x290 ctl_ioctl+0x1c4/0x4d0 _ctl_ioctl+0xe/0x20 __x64_sys_ioctl+0x7b/0xb0 do_syscall_64+0x40/0xb0 entrada_SYSCALL_64_after_hwframe+ 0x44/0xae Se soluciona asignando new_root únicamente cuando la eliminación se realiza correctamente • https://git.kernel.org/stable/c/4c84b3e0728ffe10d89c633694c35a02b5c477dc https://git.kernel.org/stable/c/c154775619186781aaf8a99333ac07437a1768d5 https://git.kernel.org/stable/c/73f27adaa73e3057a9ec464e33c4f54d34ea5de3 https://git.kernel.org/stable/c/8fbae4a1bdb5b889490cdee929e68540151536e5 https://git.kernel.org/stable/c/964d57d1962d7e68f0f578f05d9ae4a104d74851 https://git.kernel.org/stable/c/ba47e65a5de3e0e8270301a409fc63d3129fdb9e https://git.kernel.org/stable/c/89bf942314b78d454db92427201421b5dec132d9 https://git.kernel.org/stable/c/ad365e9351ac2b450e7e79932ff6abf59 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47342 – ext4: fix possible UAF when remounting r/o a mmp-protected file system
https://notcve.org/view.php?id=CVE-2021-47342
In the Linux kernel, the following vulnerability has been resolved: ext4: fix possible UAF when remounting r/o a mmp-protected file system After commit 618f003199c6 ("ext4: fix memory leak in ext4_fill_super"), after the file system is remounted read-only, there is a race where the kmmpd thread can exit, causing sbi->s_mmp_tsk to point at freed memory, which the call to ext4_stop_mmpd() can trip over. Fix this by only allowing kmmpd() to exit when it is stopped via ext4_stop_mmpd(). Bug-Report-Link: <20210629143603.2166962-1-yebin10@huawei.com> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige posible UAF al remontar el sistema de archivos protegido por r/oa mmp. Después del commit 618f003199c6 ("ext4: corrige la pérdida de memoria en ext4_fill_super"), después de que se vuelve a montar el sistema de archivos solo que hay una ejecución donde el hilo kmmpd puede salir, causando que sbi->s_mmp_tsk apunte a la memoria liberada, con la que la llamada a ext4_stop_mmpd() puede tropezar. Solucione este problema permitiendo que kmmpd() salga solo cuando se detiene a través de ext4_stop_mmpd(). Enlace de informe de error: <20210629143603.2166962-1-yebin10@huawei.com> • https://git.kernel.org/stable/c/b663890d854403e566169f7e90aed5cd6ff64f6b https://git.kernel.org/stable/c/7ed572cdf11081f8f9e07abd4bea56a3f2c4edbd https://git.kernel.org/stable/c/61bb4a1c417e5b95d9edb4f887f131de32e419cb •