Page 55 of 977 results (0.007 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

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: 0

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 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Prevent out of bounds access in performance query extensions Check that the number of perfmons userspace is passing in the copy and reset extensions is not greater than the internal kernel storage where the ids will be copied into. • https://git.kernel.org/stable/c/bae7cb5d68001a8d4ceec5964dda74bb9aab7220 https://git.kernel.org/stable/c/73ad583bd4938bf37d2709fc36901eb6f22f2722 https://git.kernel.org/stable/c/3e50d72abe50204c7b19784a66e86da29dde32c2 https://git.kernel.org/stable/c/d9536f16be3970c170571efa707c13cd089c774e https://git.kernel.org/stable/c/f32b5128d2c440368b5bf3a7a356823e235caabb •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

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: 0

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/ad80c34944d7175fa1f5c7a55066020002921a99 https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881 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/079cba4f4e307c69878226fdf5228c20a •