CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47352 – virtio-net: Add validation for used length
https://notcve.org/view.php?id=CVE-2021-47352
In the Linux kernel, the following vulnerability has been resolved: virtio-net: Add validation for used length This adds validation for used length (might come from an untrusted device) to avoid data corruption or loss. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio-net: Agregar validación para la longitud utilizada. Esto agrega validación para la longitud utilizada (puede provenir de un dispositivo que no es de confianza) para evitar la corrupción o pérdida de datos. A vulnerability was found in the Linux kernel’s virtio-net driver, where the system does not properly validate the length of data provided by an untrusted device. This lack of validation could lead to data corruption if the length of the data is incorrect or maliciously crafted. • https://git.kernel.org/stable/c/c92298d228f61589dd21657af2bea95fc866b813 https://git.kernel.org/stable/c/3133e01514c3c498f2b01ff210ee6134b70c663c https://git.kernel.org/stable/c/ba710baa1cc1b17a0483f7befe03e696efd17292 https://git.kernel.org/stable/c/ad993a95c508417acdeb15244109e009e50d8758 https://access.redhat.com/security/cve/CVE-2021-47352 https://bugzilla.redhat.com/show_bug.cgi?id=2282401 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47351 – ubifs: Fix races between xattr_{set|get} and listxattr operations
https://notcve.org/view.php?id=CVE-2021-47351
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix races between xattr_{set|get} and listxattr operations UBIFS may occur some problems with concurrent xattr_{set|get} and listxattr operations, such as assertion failure, memory corruption, stale xattr value[1]. Fix it by importing a new rw-lock in @ubifs_inode to serilize write operations on xattr, concurrent read operations are still effective, just like ext4. [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: corrige ejecucións entre las operaciones xattr_{set|get} y listxattr. UBIFS puede producir algunos problemas con las operaciones xattr_{set|get} y listxattr simultáneas, como fallas de aserción y corrupción de memoria. , valor xattr obsoleto [1]. Solucónelo importando un nuevo rw-lock en @ubifs_inode para serializar las operaciones de escritura en xattr, las operaciones de lectura simultáneas siguen siendo efectivas, al igual que ext4. [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com • https://git.kernel.org/stable/c/1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d https://git.kernel.org/stable/c/7adc05b73d91a5e3d4ca7714fa53ad9b70c53d08 https://git.kernel.org/stable/c/38dde03eb239605f428f3f1e4baa73d4933a4cc6 https://git.kernel.org/stable/c/9558612cb829f2c022b788f55d6b8437d5234a82 https://git.kernel.org/stable/c/c0756f75c22149d20fcb7d8409827cee905eb386 https://git.kernel.org/stable/c/f4e3634a3b642225a530c292fdb1e8a4007507f5 •
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 •