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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35813 – mmc: core: Avoid negative index with array access
https://notcve.org/view.php?id=CVE-2024-35813
In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid negative index with array access Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns prev_idata = idatas[i - 1], but doesn't check that the iterator i is greater than zero. Let's fix this by adding a check. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: core: evitar índice negativo con acceso a matriz Commit 4d0c8d0aef63 ("mmc: core: usar mrq.sbc en ffu cerrado") asigna prev_idata = idatas[i - 1] , pero no comprueba que el iterador i sea mayor que cero. Arreglemos esto agregando una comprobación. • https://git.kernel.org/stable/c/f49f9e802785291149bdc9c824414de4604226b4 https://git.kernel.org/stable/c/59020bf0999ff7da8aedcd00ef8f0d75d93b6d20 https://git.kernel.org/stable/c/50b8b7a22e90bab9f1949b64a88ff17ab10913ec https://git.kernel.org/stable/c/c4edcd134bb72b3b0acc884612d624e48c9d057f https://git.kernel.org/stable/c/1653a8102868264f3488c298a9f20af2add9a288 https://git.kernel.org/stable/c/eed9119f8f8e8fbf225c08abdbb58597fba807e0 https://git.kernel.org/stable/c/4d0c8d0aef6355660b6775d57ccd5d4ea2e15802 https://git.kernel.org/stable/c/b9a7339ae403035ffe7fc37cb034b3694 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35811 – wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
https://notcve.org/view.php?id=CVE-2024-35811
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: corregido el error de use after free en brcmf_cfg80211_detach Este es el parche candidato de CVE-2023-47233: https://nvd.nist.gov/vuln/detail /CVE-2023-47233 En el controlador brcm80211, comienza con la siguiente cadena de invocación para iniciar un trabajador de tiempo de espera: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg ->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); Si desconectamos el USB mediante hotplug, llamará a brcmf_usb_disconnect para realizar la limpieza. La cadena de invocación es: brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); Mientras que el activador de tiempo de espera aún puede estar ejecutándose. Esto provocará un error de use after free en cfg en brcmf_cfg80211_escan_timeout_worker. • https://git.kernel.org/stable/c/e756af5b30b008f6ffcfebf8ad0b477f6f225b62 https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169 https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1 https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731 https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744 https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35810 – drm/vmwgfx: Fix the lifetime of the bo cursor memory
https://notcve.org/view.php?id=CVE-2024-35810
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix the lifetime of the bo cursor memory The cleanup can be dispatched while the atomic update is still active, which means that the memory acquired in the atomic update needs to not be invalidated by the cleanup. The buffer objects in vmw_plane_state instead of using the builtin map_and_cache were trying to handle the lifetime of the mapped memory themselves, leading to crashes. Use the map_and_cache instead of trying to manage the lifetime of the buffer objects held by the vmw_plane_state. Fixes kernel oops'es in IGT's kms_cursor_legacy forked-bo. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: corregida la vida útil de la memoria del cursor bo. La sanitización se puede realizar mientras la actualización atómica aún está activa, lo que significa que la memoria adquirida en la actualización atómica no necesita ser invalidado por la limpieza. Los objetos del búfer en vmw_plane_state, en lugar de utilizar el map_and_cache incorporado, intentaban manejar ellos mismos la vida útil de la memoria asignada, lo que provocaba fallos. • https://git.kernel.org/stable/c/bb6780aa5a1d99e86757c0c96bfae65a46cf839e https://git.kernel.org/stable/c/86cb706a40b7e6b2221ee49a298a65ad9b46c02d https://git.kernel.org/stable/c/104a5b2772bc7c0715ae7355ccf9d294a472765c https://git.kernel.org/stable/c/ed381800ea6d9a4c7f199235a471c0c48100f0ae https://git.kernel.org/stable/c/9a9e8a7159ca09af9b1a300a6c8e8b6ff7501c76 https://access.redhat.com/security/cve/CVE-2024-35810 https://bugzilla.redhat.com/show_bug.cgi?id=2281215 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35809 – PCI/PM: Drain runtime-idle callbacks before driver removal
https://notcve.org/view.php?id=CVE-2024-35809
In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks. • https://git.kernel.org/stable/c/9a87375bb586515c0af63d5dcdcd58ec4acf20a6 https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1 https://git.kernel.org/stable/c/bbe068b24409ef740657215605284fc7cdddd491 https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674 https://git.kernel.org/stable/c/900b81caf00c89417172afe0e7e49ac4eb110f4b https://git.kernel.org/stable/c/d86ad8c3e152349454b82f37007ff6ba45f26989 https://git.kernel.org/stable/c/d534198311c345e4b062c4b88bb609efb8bd91d5 https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627 •