CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47350 – powerpc/mm: Fix lockup on kernel exec fault
https://notcve.org/view.php?id=CVE-2021-47350
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix lockup on kernel exec fault The powerpc kernel is not prepared to handle exec faults from kernel. Especially, the function is_exec_fault() will return 'false' when an exec fault is taken by kernel, because the check is based on reading current->thread.regs->trap which contains the trap from user. For instance, when provoking a LKDTM EXEC_USERSPACE test, current->thread.regs->trap is set to SYSCALL trap (0xc00), and the fault taken by the kernel is not seen as an exec fault by set_access_flags_filter(). Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix with autonuma") made it clear and handled it properly. But later on commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults") removed that handling, introducing test based on error_code. And here is the problem, because on the 603 all upper bits of SRR1 get cleared when the TLB instruction miss handler bails out to ISI. Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy search_exception_tables() verification"), an exec fault from kernel at a userspace address was indirectly caught by the lack of entry for that address in the exception tables. But after that commit the kernel mainly relies on KUAP or on core mm handling to catch wrong user accesses. Here the access is not wrong, so mm handles it. It is a minor fault because PAGE_EXEC is not set, set_access_flags_filter() should set PAGE_EXEC and voila. But as is_exec_fault() returns false as explained in the beginning, set_access_flags_filter() bails out without setting PAGE_EXEC flag, which leads to a forever minor exec fault. As the kernel is not prepared to handle such exec faults, the thing to do is to fire in bad_kernel_fault() for any exec fault taken by the kernel, as it was prior to commit d3ca587404b3. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/mm: corrige el bloqueo en el fallo de ejecución del kernel. • https://git.kernel.org/stable/c/d3ca587404b36943b02df87406054ce73cc49500 https://git.kernel.org/stable/c/a82471a14aad90f79d1608d2bcbb019f0ffb53f0 https://git.kernel.org/stable/c/d2e52d4664097a6c1f591d869ec594bd7a0d4925 https://git.kernel.org/stable/c/500f81cec9f1bfa5210aa9dd5ba9a06e22f62a35 https://git.kernel.org/stable/c/8a96ec5ebf96ad8e2ba7b1b34103a0be5140fc70 https://git.kernel.org/stable/c/cd5d5e602f502895e47e18cd46804d6d7014e65c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47349 – mwifiex: bring down link before deleting interface
https://notcve.org/view.php?id=CVE-2021-47349
In the Linux kernel, the following vulnerability has been resolved: mwifiex: bring down link before deleting interface We can deadlock when rmmod'ing the driver or going through firmware reset, because the cfg80211_unregister_wdev() has to bring down the link for us, ... which then grab the same wiphy lock. nl80211_del_interface() already handles a very similar case, with a nice description: /* * We hold RTNL, so this is safe, without RTNL opencount cannot * reach 0, and thus the rdev cannot be deleted. * * We need to do it for the dev_close(), since that will call * the netdev notifiers, and we need to acquire the mutex there * but don't know if we get there from here or from some other * place (e.g. "ip link set ... down"). */ mutex_unlock(&rdev->wiphy.mtx); ... Do similarly for mwifiex teardown, by ensuring we bring the link down first. Sample deadlock trace: [ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds. [ 247.110630] Not tainted 5.12.4 #5 [ 247.115796] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208 [ 247.133905] Call trace: [ 247.136644] __switch_to+0x130/0x170 [ 247.140643] __schedule+0x714/0xa0c [ 247.144548] schedule_preempt_disabled+0x88/0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lock_nested+0x5c/0x68 [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211] [ 247.165769] raw_notifier_call_chain+0x4c/0x78 [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4 [ 247.176305] __dev_close_many+0x7c/0x138 [ 247.180693] dev_close_many+0x7c/0x10c [ 247.184893] unregister_netdevice_many+0xfc/0x654 [ 247.190158] unregister_netdevice_queue+0xb4/0xe0 [ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211] [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211] [ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex] [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex] [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex] [ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie] [ 247.231451] pci_device_remove+0x50/0xe0 [ 247.235849] device_release_driver_internal+0x110/0x1b0 [ 247.241701] driver_detach+0x5c/0x9c [ 247.245704] bus_remove_driver+0x84/0xb8 [ 247.250095] driver_unregister+0x3c/0x60 [ 247.254486] pci_unregister_driver+0x2c/0x90 [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mwifiex: desactivar el enlace antes de eliminar la interfaz. Podemos bloquearnos al modificar el controlador o restablecer el firmware, porque cfg80211_unregister_wdev() tiene que desactivar el enlace por nosotros. .. que luego agarra el mismo candado wiphy. nl80211_del_interface() ya maneja un caso muy similar, con una buena descripción: /* * Mantenemos RTNL, por lo que esto es seguro, sin RTNL opencount no puede * llegar a 0 y, por lo tanto, rdev no se puede eliminar. * * Necesitamos hacerlo para dev_close(), ya que eso llamará * a los notificadores de netdev, y necesitamos adquirir el mutex allí * pero no sabemos si llegamos allí desde aquí o desde algún otro * lugar (por ejemplo "enlace IP configurado... inactivo"). */ mutex_unlock(&rdev->wiphy.mtx); ... Haga lo mismo con el desmontaje de mwifiex, asegurándose de que primero desconectamos el enlace. Ejemplo de seguimiento de interbloqueo: [247.103516] INFORMACIÓN: tarea rmmod:2119 bloqueada durante más de 123 segundos. [247.110630] No contaminado 5.12.4 #5 [247.115796] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [247.124557] tarea:rmmod estado:D pila: 0 pid: 2119 ppid: 2114 banderas:0x00400208 [247.133905] Rastreo de llamadas: [247.136644] __switch_to+0x130/0x170 [ 247.140643] 14/0xa0c [247.144548] Schedule_preempt_disabled+0x88/ 0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lock_nested+0x5c/0x68 [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211] [ 47.165769] raw_notifier_call_chain+0x4c/0x78 [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4 [ 247.176305] __dev_close_many+0x7c /0x138 [ 247.180693] dev_close_many+0x7c/0x10c [ 247.184893] unregister_netdevice_many+0xfc/0x654 [ 247.190158] unregister_netdevice_queue+0xb4/0xe0 [ 247.195424] 11_unregister_wdev+0xa4/0x204 [cfg80211] [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211] [ 247.208016 ] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex] [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex] [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex] [ 247.225316 ] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie] [ 247.231451] pci_device_remove+0x50/0xe0 [ 247.235849] device_release_driver_internal+0x110/0x1b0 [ 247.241701] driver_detach+0x5c/0x9c [ 247.245704] bus_remove_driver+0x84/0xb8 [ 247.250095] driver_unregister+0x3c/0x60 [ 2 47.254486] pci_unregister_driver+0x2c/0x90 [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie ] • https://git.kernel.org/stable/c/a05829a7222e9d10c416dd2dbbf3929fe6646b89 https://git.kernel.org/stable/c/a3041d39d3c14da97fa3476835aba043ba810cf0 https://git.kernel.org/stable/c/35af69c7c0490fdccfc159c6a87e4d1dc070838a https://git.kernel.org/stable/c/1f9482aa8d412b4ba06ce6ab8e333fb8ca29a06e •
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 •