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: 3EXPL: 0CVE-2021-46970 – bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue
https://notcve.org/view.php?id=CVE-2021-46970
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue A recent change created a dedicated workqueue for the state-change work with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags, but the state-change work (mhi_pm_st_worker) does not guarantee forward progress under memory pressure, and will even wait on various memory allocations when e.g. creating devices, loading firmware, etc... The work is then not part of a memory reclaim path... Moreover, this causes a warning in check_flush_dependency() since we end up in code that flushes a non-reclaim workqueue: [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [ 40.969733] Call Trace: [ 40.969740] __flush_work+0x97/0x1d0 [ 40.969745] ? wake_up_process+0x15/0x20 [ 40.969749] ? insert_work+0x70/0x80 [ 40.969750] ? • https://git.kernel.org/stable/c/8f70397876872789b2a5deba804eb6216fb5deb7 https://git.kernel.org/stable/c/abd1510c08a13c88d24b622a83c82e87ff1d3135 https://git.kernel.org/stable/c/ed541cff35cbdb695f0c98ef506dd7218883fc07 https://git.kernel.org/stable/c/0fccbf0a3b690b162f53b13ed8bc442ea33437dc •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-46969 – bus: mhi: core: Fix invalid error returning in mhi_queue
https://notcve.org/view.php?id=CVE-2021-46969
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: core: Fix invalid error returning in mhi_queue mhi_queue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update. So, since it's not an error but just delaying of doorbell update, there is no reason to return an error. This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bus: mhi: core: corrige el error no válido que regresa en mhi_queue mhi_queue devuelve un error cuando no se puede acceder al timbre en el estado actual. Esto puede suceder cuando el dispositivo no está en un estado M0, como M3, y es necesario activarlo antes de llamar a la base de datos. • https://git.kernel.org/stable/c/a8f75cb348fd52e7a5cf25991cdf9c89fb0cfd41 https://git.kernel.org/stable/c/a99b661c3187365f81026d89b1133a76cd2652b3 https://git.kernel.org/stable/c/0ecc1c70dcd32c0f081b173a1a5d89952686f271 •
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 •