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: 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 •