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: 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: 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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35808 – md/dm-raid: don't call md_reap_sync_thread() directly
https://notcve.org/view.php?id=CVE-2024-35808
In the Linux kernel, the following vulnerability has been resolved: md/dm-raid: don't call md_reap_sync_thread() directly Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'. However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/dm-raid: no llame a md_reap_sync_thread() directamente Actualmente, se llama a md_reap_sync_thread() desde raid_message() directamente sin mantener presionado 'reconfig_mutex', esto definitivamente no es seguro porque md_reap_sync_thread( ) puede cambiar muchos campos protegidos por 'reconfig_mutex'. Sin embargo, mantener 'reconfig_mutex' aquí sigue siendo problemático porque esto causará un punto muerto, por ejemplo, confirme 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Solucione este problema usando stop_sync_thread() para cancelar el registro de sync_thread, como lo hizo md/raid. • https://git.kernel.org/stable/c/be83651f0050ca8621d58d35dad558e9c45cb18f https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669 https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0 •