
CVE-2023-52638 – can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
https://notcve.org/view.php?id=CVE-2023-52638
03 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not ... • https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170 • CWE-833: Deadlock •

CVE-2024-26672 – drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'
https://notcve.org/view.php?id=CVE-2024-26672
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_f... • https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53 • CWE-476: NULL Pointer Dereference •

CVE-2024-26671 – blk-mq: fix IO hang from sbitmap wakeup race
https://notcve.org/view.php?id=CVE-2024-26671
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the followin... • https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

CVE-2023-52635 – PM / devfreq: Synchronize devfreq_monitor_[start/stop]
https://notcve.org/view.php?id=CVE-2023-52635
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Synchronize devfreq_monitor_[start/stop] There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1]. while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governo... • https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475 • CWE-414: Missing Lock Check •

CVE-2023-52633 – um: time-travel: fix time corruption
https://notcve.org/view.php?id=CVE-2023-52633
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: um: time-travel: fix time corruption In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, a... • https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab •

CVE-2024-26659 – xhci: handle isoc Babble and Buffer Overrun events properly
https://notcve.org/view.php?id=CVE-2024-26659
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior e... • https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •

CVE-2024-26656 – drm/amdgpu: fix use-after-free bug
https://notcve.org/view.php?id=CVE-2024-26656
02 Apr 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free bug The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung

CVE-2023-52622 – ext4: avoid online resizing failures due to oversized flex bg
https://notcve.org/view.php?id=CVE-2023-52622
26 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2f... • https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644 • CWE-131: Incorrect Calculation of Buffer Size •

CVE-2023-52621 – bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
https://notcve.org/view.php?id=CVE-2023-52621
26 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......... • https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612 • CWE-413: Improper Resource Locking •

CVE-2024-26644 – btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
https://notcve.org/view.php?id=CVE-2024-26644
26 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: don't abort filesystem when attempting to snapshot deleted subvolume If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort: BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng fa... • https://git.kernel.org/stable/c/c06941564027bdbc01d2df7f41e333c11cb0482d •