CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-35819 – soc: fsl: qbman: Use raw spinlock for cgr_lock
https://notcve.org/view.php?id=CVE-2024-35819
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Use raw spinlock for cgr_lock smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task. Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc: fsl: qbman: use spinlock sin formato para cgr_lock smp_call_function siempre ejecuta su devolución de llamada en un contexto IRQ duro, incluso en PREEMPT_RT, donde los spinlocks pueden dormir. Por lo tanto, necesitamos usar un spinlock sin formato para cgr_lock para asegurarnos de que no estamos esperando una tarea inactiva. Aunque este error ha existido por un tiempo, no fue evidente hasta la confirmación ef2a8d5478b9 ("net: dpaa: Ajustar la profundidad de la cola al cambiar la velocidad") que invoca smp_call_function_single a través de qman_update_cgr_safe cada vez que un enlace sube o baja. • https://git.kernel.org/stable/c/96f413f47677366e0ae03797409bfcc4151dbf9e https://git.kernel.org/stable/c/a85c525bbff4d7467d7f0ab6fed8e2f787b073d6 https://git.kernel.org/stable/c/29cd9c2d1f428c281962135ea046a9d7bda88d14 https://git.kernel.org/stable/c/5b10a404419f0532ef3ba990c12bebe118adb6d7 https://git.kernel.org/stable/c/2b3fede8225133671ce837c0d284804aa3bc7a02 https://git.kernel.org/stable/c/ff50716b7d5b7985979a5b21163cd79fb3d21d59 https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1 https://git.kernel.org/stable/c/9a3ca8292ce9fdcce122706c28c3f07bc •
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/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: -EPSS: 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 •
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: -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 •