CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35818 – LoongArch: Define the __io_aw() hook as mmiowb()
https://notcve.org/view.php?id=CVE-2024-35818
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). • https://git.kernel.org/stable/c/fa96b57c149061f71a70bd6582d995f6424fbbf4 https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167 https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0 https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35817 – drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
https://notcve.org/view.php?id=CVE-2024-35817
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: amdgpu_ttm_gart_bind establece el indicador vinculado a gtt. De lo contrario, después de que se libera GTT bo, se libera el espacio GTT y gart, pero amdgpu_ttm_backend_unbind no borrará la entrada de la tabla de páginas de gart y dejará una asignación válida. entrada que apunta a la página del sistema obsoleto. Luego, si la GPU accede a la dirección de Gart por error, leerá un valor indefinido en lugar de un error de página, lo que será más difícil de depurar y reproducir el problema real. • https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3 https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6 https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3 https://access.redhat.com/security/cve/CVE-2024-35817 https://bugzilla.redhat.com/show_bug.cgi?id=2281202 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35816 – firewire: ohci: prevent leak of left-over IRQ on unbind
https://notcve.org/view.php?id=CVE-2024-35816
In the Linux kernel, the following vulnerability has been resolved: firewire: ohci: prevent leak of left-over IRQ on unbind Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") also removed the call to free_irq() in pci_remove(), leading to a leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove() when unbinding the driver from the device remove_proc_entry: removing non-empty directory 'irq/136', leaking at least 'firewire_ohci' Call Trace: ? remove_proc_entry+0x19c/0x1c0 ? __warn+0x81/0x130 ? remove_proc_entry+0x19c/0x1c0 ? report_bug+0x171/0x1a0 ? • https://git.kernel.org/stable/c/5a95f1ded28691e69f7d6718c5dcbc149613d431 https://git.kernel.org/stable/c/43c70cbc2502cf2557105c662eeed6a15d082b88 https://git.kernel.org/stable/c/318f6d53dd425c400e35f1a9b7af682c2c6a66d6 https://git.kernel.org/stable/c/575801663c7dc38f826212b39e3b91a4a8661c33 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35815 – fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
https://notcve.org/view.php?id=CVE-2024-35815
In the Linux kernel, the following vulnerability has been resolved: fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/aio: verifique IOCB_AIO_RW antes de la conversión de struct aio_kiocb. El primer argumento kiocb_set_cancel_fn() puede apuntar a una estructura kiocb que no está incrustada dentro de struct aio_kiocb. • https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942 https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353 https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487 https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7 https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6 https://git.kernel.org/stable/c/10ca82aff58434e122c7c757cf0497c33 •
CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35814 – swiotlb: Fix double-allocation of slots due to broken alignment handling
https://notcve.org/view.php?id=CVE-2024-35814
In the Linux kernel, the following vulnerability has been resolved: swiotlb: Fix double-allocation of slots due to broken alignment handling Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool. When virtio allocates the virtqueues for the vsock device using dma_alloc_coherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer: # Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800) This ends badly (typically buffer corruption and/or a hang) because swiotlb_alloc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page. Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page. This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and resulting in alignment requirements exceeding swiotlb_max_mapping_size(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: swiotlb: corregida la doble asignación de ranuras debido a un manejo de alineación roto. Confirmación bbb73a103fbb ("swiotlb: corrija un barino en la corrección de verificación de alineación"), que fue una solución para la confirmación 0eee5ae10256 ( "swiotlb: corregir comprobaciones de alineación de ranuras"), provoca una regresión funcional con vsock en una máquina virtual mediante el rebote a través de un grupo DMA SWIOTLB restringido. Cuando virtio asigna las colas virtio para el dispositivo vsock usando dma_alloc_coherent(), la búsqueda de SWIOTLB puede devolver asignaciones de página no alineadas si 'area->index' quedó desalineado por una asignación anterior del búfer: # La dirección final entre paréntesis es la dirección de SWIOTLB devuelto a la persona que llama | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: obtuvo la ranura 1653-1657/7168 (0x9832a800) Esto termina mal (normalmente corrupción del búfer y/o bloqueo) porque swiotlb_alloc() está esperando una página -asignación alineada y, por lo tanto, devuelve ciegamente un puntero a la 'struct page' correspondiente a la asignación, por lo que asigna dos veces la primera mitad (ranura de 2 KB) de la página de 4 KB. Solucione el problema tratando la alineación de asignación por separado de cualquier requisito de alineación adicional del dispositivo, utilizando el máximo de los dos como paso para buscar las ranuras del búfer y teniendo cuidado de garantizar un mínimo de alineación de página para búferes más grandes que una página. • https://git.kernel.org/stable/c/0eee5ae1025699ea93d44fdb6ef2365505082103 https://git.kernel.org/stable/c/3e7acd6e25ba77dde48c3b721c54c89cd6a10534 https://git.kernel.org/stable/c/c88668aa6c1da240ea3eb4d128b7906e740d3cb8 https://git.kernel.org/stable/c/777391743771040e12cc40d3d0d178f70c616491 https://git.kernel.org/stable/c/04867a7a33324c9c562ee7949dbcaab7aaad1fb4 https://access.redhat.com/security/cve/CVE-2024-35814 https://bugzilla.redhat.com/show_bug.cgi?id=2281207 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-1055: Multiple Inheritance from Concrete Classes •