CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56369 – drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()
https://notcve.org/view.php?id=CVE-2024-56369
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/modes: Avoid divide by zero harder in drm_mode_vrefresh() drm_mode_vrefresh() is trying to avoid divide by zero by checking whether htotal or vtotal are zero. But we may still end up with a div-by-zero of vtotal*htotal*... In the Linux kernel, the following vulnerability has been resolved: drm/modes: Avoid divide by zero harder in drm_mode_vrefresh() drm_mode_vrefresh() is trying to avoid divide by zero by checking whether htotal or vto... • https://git.kernel.org/stable/c/e7c7b48a0fc5ed83baae400a1b15e33978c25d7f •
CVSS: 7.2EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56368 – ring-buffer: Fix overflow in __rb_map_vma
https://notcve.org/view.php?id=CVE-2024-56368
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix overflow in __rb_map_vma An overflow occurred when performing the following calculation: nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; Add a check before the calculation to avoid this problem. syzbot reported this as a slab-out-of-bounds in __rb_map_vma: BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058 Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836 CPU... • https://git.kernel.org/stable/c/117c39200d9d760cbd5944bb89efb7b9c51965aa •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-55916 – Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet
https://notcve.org/view.php?id=CVE-2024-55916
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is fully initialized, we can hit the panic below: hv_utils: Registering HyperV Utility Driver hv_vmbus: registering driver hv_utils ... BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1 RIP: 0010:hv_pkt_iter_first+0x1... • https://git.kernel.org/stable/c/e0fa3e5e7df61eb2c339c9f0067c202c0cdeec2c •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-55881 – KVM: x86: Play nice with protected guests in complete_hypercall_exit()
https://notcve.org/view.php?id=CVE-2024-55881
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Play nice with protected guests in complete_hypercall_exit() Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bit hypercall when completing said hypercall. For guests with protected state, e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bit mode as the vCPU state needed to detect 64-bit mode is unavailable. Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGE hypercall vi... • https://git.kernel.org/stable/c/5969e2435cbd7f0ce8c28d717bfc39987ee8d8f1 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-54680 – smb: client: fix TCP timers deadlock after rmmod
https://notcve.org/view.php?id=CVE-2024-54680
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: smb: client: fix TCP timers deadlock after rmmod Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") fixed a netns UAF by manually enabled socket refcounting (sk->sk_net_refcnt=1 and sock_inuse_add(net, 1)). The reason the patch worked for that bug was because we now hold references to the netns (get_net_track() gets a ref internally) and they're properly released (internally, on __sk_destruct()), but only because ... • https://git.kernel.org/stable/c/e8c71494181153a134c96da28766a57bd1eac8cb •
CVSS: 5.6EPSS: 0%CPEs: 2EXPL: 0CVE-2024-54455 – accel/ivpu: Fix general protection fault in ivpu_bo_list()
https://notcve.org/view.php?id=CVE-2024-54455
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix general protection fault in ivpu_bo_list() Check if ctx is not NULL before accessing its fields. • https://git.kernel.org/stable/c/37dee2a2f4330a030abc5674bcec25ccc4addbcc •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-54193 – accel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal()
https://notcve.org/view.php?id=CVE-2024-54193
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal() Move pm_runtime_set_active() to ivpu_pm_init() so when ivpu_ipc_send_receive_internal() is executed before ivpu_pm_enable() it already has correct runtime state, even if last resume was not successful. In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal() Move pm_runtime_set_active() to ivpu_pm_init() so when ivpu_... • https://git.kernel.org/stable/c/8ed520ff4682aaaef7d124bd9c0950092fddb9c1 •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53690 – nilfs2: prevent use of deleted inode
https://notcve.org/view.php?id=CVE-2024-53690
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent use of deleted inode syzbot reported a WARNING in nilfs_rmdir. [1] Because the inode bitmap is corrupted, an inode with an inode number that should exist as a ".nilfs" file was reassigned by nilfs_mkdir for "file0", causing an inode duplication during execution. And this causes an underflow of i_nlink in rmdir operations. The inode is used twice by the same task to unmount and remove directories ".nilfs" and "file0", it trig... • https://git.kernel.org/stable/c/d25006523d0b9e49fd097b2e974e7c8c05bd7f54 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 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/e4b168c64da06954be5d520f6c16469b1cadc069 •
CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-52319 – mm: use aligned address in clear_gigantic_page()
https://notcve.org/view.php?id=CVE-2024-52319
11 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: mm: use aligned address in clear_gigantic_page() In current kernel, hugetlb_no_page() calls folio_zero_user() with the fault address. Where the fault address may be not aligned with the huge page size. Then, folio_zero_user() may call clear_gigantic_page() with the address, while clear_gigantic_page() requires the address to be huge page size aligned. So, this may cause memory corruption or information leak, addtional, use more obvious nami... • https://git.kernel.org/stable/c/78fefd04c123493bbf28434768fa577b2153c79b •