CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49985 – i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
https://notcve.org/view.php?id=CVE-2024-49985
In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex. • https://git.kernel.org/stable/c/4e7bca6fc07bf9526d797b9787dcb21e40cd10cf https://git.kernel.org/stable/c/9b8bc33ad64192f54142396470cc34ce539a8940 https://git.kernel.org/stable/c/1883cad2cc629ded4a3556c0bbb8b42533ad8764 https://git.kernel.org/stable/c/c2024b1a583ab9176c797ea1e5f57baf8d5e2682 https://git.kernel.org/stable/c/22a1f8a5b56ba93d3e8b7a1dafa24e01c8bb48ba https://git.kernel.org/stable/c/fac3c9f7784e8184c0338e9f0877b81e55d3ef1c https://git.kernel.org/stable/c/894cd5f5fd9061983445bbd1fa3d81be43095344 https://git.kernel.org/stable/c/048bbbdbf85e5e00258dfb12f5e368f90 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-49982 – aoe: fix the potential use-after-free problem in more places
https://notcve.org/view.php?id=CVE-2024-49982
In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue. • https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65 https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4 https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62 https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662 https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99 https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881 https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20a •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49981 – media: venus: fix use after free bug in venus_remove due to race condition
https://notcve.org/view.php?id=CVE-2024-49981
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. • https://git.kernel.org/stable/c/af2c3834c8ca7cc65d15592ac671933df8848115 https://git.kernel.org/stable/c/60b6968341a6dd5353554f3e72db554693a128a5 https://git.kernel.org/stable/c/bf6be32e2d39f6301ff1831e249d32a8744ab28a https://git.kernel.org/stable/c/2a541fcc0bd2b05a458e9613376df1289ec11621 https://git.kernel.org/stable/c/b0686aedc5f1343442d044bd64eeac7e7a391f4e https://git.kernel.org/stable/c/d925e9f7fb5a2dbefd1a73fc01061f38c7becd4c https://git.kernel.org/stable/c/10941d4f99a5a34999121b314afcd9c0a1c14f15 https://git.kernel.org/stable/c/c5a85ed88e043474161bbfe54002c89c1 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49975 – uprobes: fix kernel info leak via "[uprobes]" vma
https://notcve.org/view.php?id=CVE-2024-49975
In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway. • https://git.kernel.org/stable/c/d4b3b6384f98f8692ad0209891ccdbc7e78bbefe https://git.kernel.org/stable/c/f561b48d633ac2e7d0d667020fc634a96ade33a0 https://git.kernel.org/stable/c/21cb47db1ec9765f91304763a24565ddc22d2492 https://git.kernel.org/stable/c/24141df5a8615790950deedd926a44ddf1dfd6d8 https://git.kernel.org/stable/c/5b981d8335e18aef7908a068529a3287258ff6d8 https://git.kernel.org/stable/c/2aa45f43709ba2082917bd2973d02687075b6eee https://git.kernel.org/stable/c/9634e8dc964a4adafa7e1535147abd7ec29441a6 https://git.kernel.org/stable/c/34820304cc2cd1804ee1f8f3504ec7781 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49974 – NFSD: Limit the number of concurrent async COPY operations
https://notcve.org/view.php?id=CVE-2024-49974
In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches. • https://git.kernel.org/stable/c/b4e21431a0db4854b5023cd5af001be557e6c3db https://git.kernel.org/stable/c/6a488ad7745b8f64625c6d3a24ce7e448e83f11b https://git.kernel.org/stable/c/aadc3bbea163b6caaaebfdd2b6c4667fbc726752 •