CVSS: 8.4EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46973 – net: qrtr: Avoid potential use after free in MHI send
https://notcve.org/view.php?id=CVE-2021-46973
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Avoid potential use after free in MHI send It is possible that the MHI ul_callback will be invoked immediately following the queueing of the skb for transmission, leading to the callback decrementing the refcount of the associated sk and freeing the skb. As such the dereference of skb and the increment of the sk refcount must happen before the skb is queued, to avoid the skb to be used after free and potentially the sk to drop its last refcount.. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qrtr: Evite el potencial use after free en el envío MHI. Es posible que MHI ul_callback se invoque inmediatamente después de la puesta en cola del skb para la transmisión, lo que provocará que la devolución de llamada disminuya el recuento del sk asociado y liberación del skb. Como tal, la desreferencia de skb y el incremento del refcount de sk deben ocurrir antes de que el skb se ponga en cola, para evitar que el skb haga use after free y potencialmente que el sk elimine su último refcount. • https://git.kernel.org/stable/c/6e728f321393b1fce9e1c2c3e55f9f7c15991321 https://git.kernel.org/stable/c/48ec949ac979b4b42d740f67b6177797af834f80 https://git.kernel.org/stable/c/ea474054c2cc6e1284604b21361f475c7cc8c0a0 https://git.kernel.org/stable/c/03c649dee8b1eb5600212a249542a70f47a5ab40 https://git.kernel.org/stable/c/47a017f33943278570c072bc71681809b2567b3a • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46972 – ovl: fix leaked dentry
https://notcve.org/view.php?id=CVE-2021-46972
In the Linux kernel, the following vulnerability has been resolved: ovl: fix leaked dentry Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a metacopy error, which leads to dentry leaks when shutting down the related superblock: overlayfs: refusing to follow metacopy origin for (/file0) ... BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] ... WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 ... RIP: 0010:umount_check.cold+0x107/0x14d ... Call Trace: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0 ? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820 ? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160 ? • https://git.kernel.org/stable/c/6815f479ca90ee7fd2e28b2a420f796b974155fe https://git.kernel.org/stable/c/71d58457a8afc650da5d3292a7f7029317654d95 https://git.kernel.org/stable/c/cf3e3330bc5719fa9d658e3e2f596bde89344a94 https://git.kernel.org/stable/c/d587cfaef72b1b6f4b2774827123bce91f497cc8 https://git.kernel.org/stable/c/eaab1d45cdb4bb0c846bd23c3d666d5b90af7b41 https://access.redhat.com/security/cve/CVE-2021-46972 https://bugzilla.redhat.com/show_bug.cgi?id=2266831 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46971 – perf/core: Fix unconditional security_locked_down() call
https://notcve.org/view.php?id=CVE-2021-46971
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task's type has the corresponding "lockdown" class permission ("integrity" or "confidentiality") allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when its result would be honored. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/core: corrige la llamada incondicional a security_locked_down() Actualmente, el estado de bloqueo se consulta incondicionalmente, aunque su resultado se usa solo si el bit PERF_SAMPLE_REGS_INTR está establecido en attr.sample_type. Si bien eso no importa en el caso del Lockdown LSM, causa problemas con la implementación del gancho de bloqueo de SELinux. • https://git.kernel.org/stable/c/b0c8fdc7fdb77586c3d1937050925b960743306e https://git.kernel.org/stable/c/b246759284d6a2bc5b6f1009caeeb3abce2ec9ff https://git.kernel.org/stable/c/4348d3b5027bc3ff6336368b6c60605d4ef8e1ce https://git.kernel.org/stable/c/f5809ca4c311b71bfaba6d13f4e39eab0557895e https://git.kernel.org/stable/c/c7b0208ee370b89d20486fae71cd9abb759819c1 https://git.kernel.org/stable/c/08ef1af4de5fe7de9c6d69f1e22e51b66e385d9b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46968 – s390/zcrypt: fix zcard and zqueue hot-unplug memleak
https://notcve.org/view.php?id=CVE-2021-46968
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix zcard and zqueue hot-unplug memleak Tests with kvm and a kmemdebug kernel showed, that on hot unplug the zcard and zqueue structs for the unplugged card or queue are not properly freed because of a mismatch with get/put for the embedded kref counter. This fix now adjusts the handling of the kref counters. With init the kref counter starts with 1. This initial value needs to drop to zero with the unregister of the card or queue to trigger the release and free the object. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/zcrypt: corrige zcard y zqueue hot-unplug memleak Las pruebas con kvm y un kernel kmemdebug mostraron que, al desconectar en caliente, las estructuras zcard y zqueue para la tarjeta o cola desconectada no están liberado correctamente debido a una discrepancia con get/put para el contador kref integrado. Esta solución ahora ajusta el manejo de los contadores kref. • https://git.kernel.org/stable/c/29c2680fd2bf3862ff5cf2957f198512493156f9 https://git.kernel.org/stable/c/026499a9c2e002e621ad568d1378324ae97e5524 https://git.kernel.org/stable/c/055a063a18bcd19b93709e3eac8078d6b2f04599 https://git.kernel.org/stable/c/971dc8706cee47393d393905d294ea47e39503d3 https://git.kernel.org/stable/c/70fac8088cfad9f3b379c9082832b4d7532c16c2 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46967 – vhost-vdpa: fix vm_flags for virtqueue doorbell mapping
https://notcve.org/view.php?id=CVE-2021-46967
In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: fix vm_flags for virtqueue doorbell mapping The virtqueue doorbell is usually implemented via registeres but we don't provide the necessary vma->flags like VM_PFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vm_flags. With this patch, try to map doorbell via IOTLB will fail with bad address. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vhost-vdpa: corrige vm_flags para el mapeo del timbre virtqueue El timbre virtqueue generalmente se implementa a través de registros, pero no proporcionamos los vma->flags necesarios como VM_PFNMAP. • https://git.kernel.org/stable/c/ddd89d0a059d8e9740c75a97e0efe9bf07ee51f9 https://git.kernel.org/stable/c/3b8b6399666a29daa30b0bb3f5c9e3fc81c5a6a6 https://git.kernel.org/stable/c/940230a5c31e2714722aee04c521a21f484b4df7 https://git.kernel.org/stable/c/93dbbf20e3ffad14f04227a0b7105f6e6f0387ce https://git.kernel.org/stable/c/3a3e0fad16d40a2aa68ddf7eea4acdf48b22dd44 •