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