Vulnerabilities > Linux > Linux Kernel > 5.18.12
| DATE | CVE | VULNERABILITY TITLE | RISK |
|---|---|---|---|
| 2025-03-27 | CVE-2023-52991 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer in skb_segment_list Commit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") introduced UDP listifyed GRO. | 5.5 |
| 2025-03-27 | CVE-2023-52993 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. | 5.5 |
| 2025-03-27 | CVE-2023-53001 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: drm/drm_vma_manager: Add drm_vma_node_allow_once() Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. | 5.5 |
| 2025-03-27 | CVE-2023-53002 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix a memory leak with reused mmap_offset drm_vma_node_allow() and drm_vma_node_revoke() should be called in balanced pairs. | 5.5 |
| 2025-03-27 | CVE-2023-53005 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: trace_events_hist: add check for return value of 'create_hist_field' Function 'create_hist_field' is called recursively at trace_events_hist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. | 5.5 |
| 2025-03-27 | CVE-2023-53008 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential memory leaks in session setup Make sure to free cifs_ses::auth_key.response before allocating it as we might end up leaking memory in reconnect or mounting. | 5.5 |
| 2025-03-27 | CVE-2023-53011 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: net: stmmac: enable all safety features by default In the original implementation of dwmac5 commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features") all safety features were enabled by default. Later it seems some implementations didn't have support for all the features, so in commit 5ac712dcdfef ("net: stmmac: enable platform specific safety features") the safety_feat_cfg structure was added to the callback and defined for some platforms to selectively enable these safety features. The problem is that only certain platforms were given that software support. | 5.5 |
| 2025-03-27 | CVE-2023-53013 | Improper Locking vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: ptdma: pt_core_execute_cmd() should use spinlock The interrupt handler (pt_core_irq_handler()) of the ptdma driver can be called from interrupt context. | 5.5 |
| 2025-03-27 | CVE-2023-53015 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: HID: betop: check shape of output reports betopff_init() only checks the total sum of the report counts for each report field to be at least 4, but hid_betopff_play() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hid_betopff_play(). | 5.5 |
| 2025-03-27 | CVE-2023-53016 | Improper Locking vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix possible deadlock in rfcomm_sk_state_change syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock() rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk) This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes. | 5.5 |