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: 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: 7EXPL: 0CVE-2024-49983 – ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free
https://notcve.org/view.php?id=CVE-2024-49983
In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes. • https://git.kernel.org/stable/c/8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 https://git.kernel.org/stable/c/8c26d9e53e5fbacda0732a577e97c5a5b7882aaf https://git.kernel.org/stable/c/a34bed978364114390162c27e50fca50791c568d https://git.kernel.org/stable/c/6367d3f04c69e2b8770b8137bd800e0784b0abbc https://git.kernel.org/stable/c/1b558006d98b7b0b730027be0ee98973dd10ee0d https://git.kernel.org/stable/c/3ff710662e8d86a63a39b334e9ca0cb10e5c14b0 https://git.kernel.org/stable/c/63adc9016917e6970fb0104ee5fd6770f02b2d80 https://git.kernel.org/stable/c/5c0f4cc84d3a601c99bc5e6e6eb1cbda5 •
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 •