CVSS: 5.5EPSS: %CPEs: 3EXPL: 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/c47ed91156daf328601d02b58d52d9804da54108 •
CVSS: 5.5EPSS: %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: %CPEs: 3EXPL: 0CVE-2024-48873 – wifi: rtw89: check return value of ieee80211_probereq_get() for RNR
https://notcve.org/view.php?id=CVE-2024-48873
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: check return value of ieee80211_probereq_get() for RNR The return value of ieee80211_probereq_get() might be NULL, so check it before using to avoid NULL pointer access. Addresses-Coverity-ID: 1529805 ("Dereference null return value") In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: check return value of ieee80211_probereq_get() for RNR The return value of ieee80211_probereq_get() might be NULL, ... • https://git.kernel.org/stable/c/1a0f54cb3fea5d087440b2bae03202c445156a8d •
CVSS: 5.5EPSS: %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: %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: %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: %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 •
CVSS: 7.1EPSS: %CPEs: 5EXPL: 0CVE-2024-45828 – i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request
https://notcve.org/view.php?id=CVE-2024-45828
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when the ring is being stopped. Depending on timing between ring stop request completion, interrupt handler removal and code execution this may lead to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run after the io_data pointer is set to NULL in hci_dma_cleanup(). Prevent this my masking the ... • https://git.kernel.org/stable/c/a6cddf68b3405b272b5a3cad9657be0b02b34bf4 •
CVSS: 5.5EPSS: %CPEs: 7EXPL: 0CVE-2024-43098 – i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock
https://notcve.org/view.php?id=CVE-2024-43098
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice. v2: - Modified the title and commit message ============================================ WARNING: possible recursive locking detected 6.11.0-mainline ---------... • https://git.kernel.org/stable/c/9a2173660ee53d5699744f02e6ab7bf89fcd0b1a •
CVSS: 7.1EPSS: %CPEs: 3EXPL: 0CVE-2024-41935 – f2fs: fix to shrink read extent node in batches
https://notcve.org/view.php?id=CVE-2024-41935
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to shrink read extent node in batches We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue. This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time ho... • https://git.kernel.org/stable/c/295b50e95e900da31ff237e46e04525fa799b2cf •