CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-57809 – PCI: imx6: Fix suspend/resume support on i.MX6QDL
https://notcve.org/view.php?id=CVE-2024-57809
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: PCI: imx6: Fix suspend/resume support on i.MX6QDL The suspend/resume functionality is currently broken on the i.MX6QDL platform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf This patch addresses the issue by sharing most of the suspend/resume sequences used by other i.MX devices, while avoiding modifications to critical registers that disrupt the PCIe functionality. It targets the same problem... • https://git.kernel.org/stable/c/ac43ea3d27a8f9beadf3af66c9ea4a566ebfff1f •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-57807 – scsi: megaraid_sas: Fix for a potential deadlock
https://notcve.org/view.php?id=CVE-2024-57807
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix for a potential deadlock This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex. • https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-57798 – drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()
https://notcve.org/view.php?id=CVE-2024-57798
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req(). Avoid th... • https://git.kernel.org/stable/c/f61b2e5e7821f868d6afc22382a66a30ee780ba0 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53685 – ceph: give up on paths longer than PATH_MAX
https://notcve.org/view.php?id=CVE-2024-53685
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: ceph: give up on paths longer than PATH_MAX If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability. I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let's remove it and... • https://git.kernel.org/stable/c/d42ad3f161a5a487f81915c406f46943c7187a0a •
CVSS: 7.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53680 – ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()
https://notcve.org/view.php?id=CVE-2024-53680
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init() Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ip_vs_protocol_init(), triggering the following objtool warning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() At run... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-48875 – btrfs: don't take dev_replace rwsem on task already holding it
https://notcve.org/view.php?id=CVE-2024-48875
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: don't take dev_replace rwsem on task already holding it Running fstests btrfs/011 with MKFS_OPTIONS="-O rst" to force the usage of the RAID stripe-tree, we get the following splat from lockdep: BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started ============================================ WARNING: possible recursive locking detected 6.11.0-rc3-btrfs-for-next #599 Not tainted -----------------------------... • https://git.kernel.org/stable/c/a5bc4e030f50fdbb1fbc69acc1e0c5f57c79d044 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47809 – dlm: fix possible lkb_resource null dereference
https://notcve.org/view.php?id=CVE-2024-47809
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way a... • https://git.kernel.org/stable/c/6fbdc3980b70e9c1c86eccea7d5ee68108008fa7 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-47794 – bpf: Prevent tailcall infinite loop caused by freplace
https://notcve.org/view.php?id=CVE-2024-47794
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tailcall infinite loop caused by freplace There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace. In an upcoming selftest, the attach target for entry_freplace of tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in entry_freplace leads to entry_tc. This results in an infinite loop: entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc. The probl... • https://git.kernel.org/stable/c/987aa730bad3e1ef66d9f30182294daa78f6387d •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-47143 – dma-debug: fix a possible deadlock on radix_lock
https://notcve.org/view.php?id=CVE-2024-47143
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: dma-debug: fix a possible deadlock on radix_lock radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock(): CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one ... • https://git.kernel.org/stable/c/3ccce34a5c3f5c9541108a451657ade621524b32 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47141 – pinmux: Use sequential access to access desc->pinmux data
https://notcve.org/view.php?id=CVE-2024-47141
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: pinmux: Use sequential access to access desc->pinmux data When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner. Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path an... • https://git.kernel.org/stable/c/2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b •