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. ... 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. • 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. ... 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: 5.5EPSS: 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. ... 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. • 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. ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: evita la sobrelectura y la corrupción de HDCP. • 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 •