CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49989 – drm/amd/display: fix double free issue during amdgpu module unload
https://notcve.org/view.php?id=CVE-2024-49989
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] <TASK> [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? • https://git.kernel.org/stable/c/cf6f3ebd6312d465fee096d1f58089b177c7c67f https://git.kernel.org/stable/c/7af9e6fa63dbd43a61d4ecc8f59426596a75e507 https://git.kernel.org/stable/c/3c0ff4de45ce2c5f7997a1ffa6eefee4b79e6b58 https://git.kernel.org/stable/c/20b5a8f9f4670a8503aa9fa95ca632e77c6bf55d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49988 – ksmbd: add refcnt to ksmbd_conn struct
https://notcve.org/view.php?id=CVE-2024-49988
In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used. • https://git.kernel.org/stable/c/18f06bacc197d4ac9b518ad1c69999bc3d83e7aa https://git.kernel.org/stable/c/9fd3cde4628bcd3549ab95061f2bab74d2ed4f3b https://git.kernel.org/stable/c/e9dac92f4482a382e8c0fe1bc243da5fc3526b0c https://git.kernel.org/stable/c/ee426bfb9d09b29987369b897fe9b6485ac2be27 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49987 – bpftool: Fix undefined behavior in qsort(NULL, 0, ...)
https://notcve.org/view.php?id=CVE-2024-49987
In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: "Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined." To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer. • https://git.kernel.org/stable/c/c2d9f9a7837ab29ccae0c42252f17d436bf0a501 https://git.kernel.org/stable/c/2e0f6f33f2aa87493b365a38a8fd87b8854b7734 https://git.kernel.org/stable/c/c208b02827eb642758cef65641995fd3f38c89af https://git.kernel.org/stable/c/f04e2ad394e2755d0bb2d858ecb5598718bf00d5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49986 – platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors
https://notcve.org/view.php?id=CVE-2024-49986
In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed. • https://git.kernel.org/stable/c/5eba0141206ea521bbcfcf5067c174e825e943dd https://git.kernel.org/stable/c/aac871e493fc8809e60209d9899b1af07e9dbfc8 https://git.kernel.org/stable/c/f08adc5177bd4343df09033f62ab562c09ba7f7d https://git.kernel.org/stable/c/73a98cf79e4dbfa3d0c363e826c65aae089b313c https://git.kernel.org/stable/c/2fae3129c0c08e72b1fe93e61fd8fd203252094a •
CVSS: -EPSS: 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
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/d6f1250a4d5773f447740b9fe37b8692105796d4 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/894cd5f5fd9061983445bbd1fa3d81be4 •