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 •
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 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2021-46966 – ACPI: custom_method: fix potential use-after-free issue
https://notcve.org/view.php?id=CVE-2021-46966
In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: custom_method: soluciona un posible problema de use-after-free En cm_write(), buf siempre se libera al llegar al final de la función. Si el recuento solicitado es menor que table.length, el búfer asignado se liberará, pero las llamadas posteriores a cm_write() seguirán intentando acceder a él. Elimine el kfree(buf) incondicional al final de la función y establezca el buf en NULL en la ruta de error -EINVAL para que coincida con el resto de la función. • https://git.kernel.org/stable/c/4bda2b79a9d04c8ba31681c66e95877dbb433416 https://git.kernel.org/stable/c/5c12dadcbef8cd55ef1f5dac799bfcbb7ea7db1d https://git.kernel.org/stable/c/35b88a10535edcf62d3e6b7893a8cd506ff98a24 https://git.kernel.org/stable/c/e4467fb6ef547aa352dc03397f9474ec84eced5b https://git.kernel.org/stable/c/03d1571d9513369c17e6848476763ebbd10ec2cb https://git.kernel.org/stable/c/70424999fbf1f160ade111cb9baab51776e0f9c2 https://git.kernel.org/stable/c/06cd4a06eb596a888239fb8ceb6ea15677cab396 https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3 •