CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-49985 – i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
https://notcve.org/view.php?id=CVE-2024-49985
21 Oct 2024 — 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 perfo... • https://git.kernel.org/stable/c/4e7bca6fc07bf9526d797b9787dcb21e40cd10cf •
CVSS: 9.0EPSS: 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
21 Oct 2024 — 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 aoecm... • https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99 •
CVSS: 7.0EPSS: 0%CPEs: 9EXPL: 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
21 Oct 2024 — 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_des... • https://git.kernel.org/stable/c/af2c3834c8ca7cc65d15592ac671933df8848115 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49975 – uprobes: fix kernel info leak via "[uprobes]" vma
https://notcve.org/view.php?id=CVE-2024-49975
21 Oct 2024 — 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. In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak... • https://git.kernel.org/stable/c/d4b3b6384f98f8692ad0209891ccdbc7e78bbefe •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49974 – NFSD: Limit the number of concurrent async COPY operations
https://notcve.org/view.php?id=CVE-2024-49974
21 Oct 2024 — 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 pat... • https://git.kernel.org/stable/c/9e52ff544e0bfa09ee339fd7b0937ee3c080c24e •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-49973 – r8169: add tally counter fields added with RTL8125
https://notcve.org/view.php?id=CVE-2024-49973
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it. In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fi... • https://git.kernel.org/stable/c/f1bce4ad2f1cee6759711904b9fffe4a3dd8af87 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49972 – drm/amd/display: Deallocate DML memory if allocation fails
https://notcve.org/view.php?id=CVE-2024-49972
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails. In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fa... • https://git.kernel.org/stable/c/80345daa5746184195f2d383a2f1bad058f0f94c •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49971 – drm/amd/display: Increase array size of dummy_boolean
https://notcve.org/view.php?id=CVE-2024-49971
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:... • https://git.kernel.org/stable/c/e9e48b7bb9cf3b78f0305ef0144aaf61da0a83d8 •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49970 – drm/amd/display: Implement bounds check for stream encoder creation in DCN401
https://notcve.org/view.php?id=CVE-2024-49970
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access ... • https://git.kernel.org/stable/c/b219b46ad42df1dea9258788bcfea37181f3ccb2 •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49969 – drm/amd/display: Fix index out of bounds in DCN30 color transformation
https://notcve.org/view.php?id=CVE-2024-49969
21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i'... • https://git.kernel.org/stable/c/7ab69af56a23859b647dee69fa1052c689343621 •