CVSS: 9.1EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47348 – drm/amd/display: Avoid HDCP over-read and corruption
https://notcve.org/view.php?id=CVE-2021-47348
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid HDCP over-read and corruption Instead of reading the desired 5 bytes of the actual target field, the code was reading 8. This could result in a corrupted value if the trailing 3 bytes were non-zero, so instead use an appropriately sized and zero-initialized bounce buffer, and read only 5 bytes before casting to u64. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: evita la sobrelectura y la corrupción de HDCP. En lugar de leer los 5 bytes deseados del campo de destino real, el código leía 8. Esto podría resultar en un archivo dañado. valor si los 3 bytes finales fueran distintos de cero, por lo tanto, utilice un búfer de rebote de tamaño adecuado e inicializado en cero, y lea solo 5 bytes antes de convertir a u64. • https://git.kernel.org/stable/c/c5b518f4b98dbb2bc31b6a55e6aaa1e0e2948f2e https://git.kernel.org/stable/c/44c7c901cb368a9f2493748f213b247b5872639f https://git.kernel.org/stable/c/3b2b93a485fb7a970bc8b5daef16f4cf579d172f https://git.kernel.org/stable/c/06888d571b513cbfc0b41949948def6cb81021b2 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47347 – wl1251: Fix possible buffer overflow in wl1251_cmd_scan
https://notcve.org/view.php?id=CVE-2021-47347
In the Linux kernel, the following vulnerability has been resolved: wl1251: Fix possible buffer overflow in wl1251_cmd_scan Function wl1251_cmd_scan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wl1251: corrige posible desbordamiento del buffer en wl1251_cmd_scan. La función wl1251_cmd_scan llama a memcpy sin comprobar la longitud. Endurecer comprobando que el largo esté dentro del tamaño máximo permitido. • https://git.kernel.org/stable/c/57ad99ae3c6738ba87bad259bb57c641ca68ebf6 https://git.kernel.org/stable/c/d3d8b9c9c7843dce31e284927d4c9904fd5a510a https://git.kernel.org/stable/c/0f6c0488368c9ac1aa685821916fadba32f5d1ef https://git.kernel.org/stable/c/115103f6e3f1c26c473766c16439c7c8b235529a https://git.kernel.org/stable/c/d71dddeb5380613f9ef199f3e7368fd78fb1a46e https://git.kernel.org/stable/c/c5e4a10d7bd5d4f419d8b9705dff60cf69b302a1 https://git.kernel.org/stable/c/302e2ee34c5f7c5d805b7f835d9a6f2b43474e2a https://git.kernel.org/stable/c/40af3960a15339e8bbd3be50c3bc7b35e •
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 •