CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46974 – bpf: Fix masking negation logic upon negative dst register
https://notcve.org/view.php?id=CVE-2021-46974
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix masking negation logic upon negative dst register The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la lógica de negación de enmascaramiento en el registro dst negativo. La lógica de negación para el caso en el que off_reg se encuentra en el registro dst no es correcta, dado que entonces no podemos simplemente invertir la adición a un sub o viceversa. • https://git.kernel.org/stable/c/ae03b6b1c880a03d4771257336dc3bca156dd51b https://git.kernel.org/stable/c/f92a819b4cbef8c9527d9797110544b2055a4b96 https://git.kernel.org/stable/c/979d63d50c0c0f7bc537bf821e056cc9fe5abd38 https://git.kernel.org/stable/c/078da99d449f64ca04d459cdbdcce513b64173cd https://git.kernel.org/stable/c/4d542ddb88fb2f39bf7f14caa2902f3e8d06f6ba https://git.kernel.org/stable/c/0e2dfdc74a7f4036127356d42ea59388f153f42c https://git.kernel.org/stable/c/53e0db429b37a32b8fc706d0d90eb4583ad13848 https://git.kernel.org/stable/c/2cfa537674cd1051a3b8111536d77d055 •
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: 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 •