Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
nt when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4, - reword commit description. (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7) References: - https://git.kernel.org/stable/c/5e784a7d07af42057c0576fb647b482f4cb0dc2c - https://git.kernel.org/stable/c/6ab7d33617559cced63d467928f478ea5c459021 - https://git.kernel.org/stable/c/5c7591b8574c52c56b3994c2fbef1a3a311b5715 - https://git.kernel.org/stable/c/9159db27fb19bbf1c91b5c9d5285e66cc96cc5ff - https://git.kernel.org/stable/c/e0e6b416b25ee14716f3549e0cbec1011b193809
CVE ID: CVE-2023-53088 State: PUBLISHED Published: 2025-05-02T15:55:34.840Z Last Updated: 2025-05-04T12:50:22.344Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: fix UaF in listener shutdown As reported by Christoph after having refactored the passive socket initialization, the mptcp listener shutdown path is prone to an UaF issue. BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0 Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266 CPU: 1 PID: 1266 Comm: syz-executor731 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS re
nted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 kasan_check_range+0x14a/0x1a0 _raw_spin_lock_bh+0x73/0xe0 subflow_error_report+0x6d/0x110 sk_error_report+0x3b/0x190 tcp_disconnect+0x138c/0x1aa0 inet_child_forget+0x6f/0x2e0 inet_csk_listen_stop+0x209/0x1060 __mptcp_close_ssk+0x52d/0x610 mptcp_destroy_common+0x165/0x640 mptcp_destroy+0x13/0x80 __mptcp_destroy_sock+0xe7/0x270 __mptcp_close+0x70e/0x9b0 mptcp_close+0x2b/0x150 inet_release+0xe9/0x1f0 __sock_release+0xd2/0x280 sock_c
ock+0xe7/0x270 __mptcp_close+0x70e/0x9b0 mptcp_close+0x2b/0x150 inet_release+0xe9/0x1f0 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc The msk grace period can legitly expire in between the last reference count dropped in mptcp_subflow_queue_clean() and the later eventual access in inet_csk_listen_stop() After the previous patch we don't need anymore special-casing msk listener socket cleanup: the mptcp worker will process each of the unaccepted msk sockets. Just drop the now unnecessary code. Please note this
the mptcp worker will process each of the unaccepted msk sockets. Just drop the now unnecessary code. Please note this commit depends on the two parent ones: mptcp: refactor passive socket initialization mptcp: use the workqueue to destroy unaccepted sockets References: - https://git.kernel.org/stable/c/5564be74a22a61855f8b8c100d8c4abb003bb792 - https://git.kernel.org/stable/c/0f4f4cf5d32f10543deb946a37111e714579511e - https://git.kernel.org/stable/c/0a3f4f1f9c27215e4ddcd312558342e57b93e518
CVE ID: CVE-2023-53089 State: PUBLISHED Published: 2025-05-02T15:55:35.498Z Last Updated: 2025-05-04T07:49:36.846Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix task hung in ext4_xattr_delete_inode Syzbot reported a hung task problem: ================================================================== INFO: task syz-executor232:5073 blocked for more than 143 seconds. Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004 Call Trace: <TASK> context_switch kernel/sched/core.c
yz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004 Call Trace: <TASK> context_switch kernel/sched/core.c:5244 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6555 schedule+0xcb/0x190 kernel/sched/core.c:6631 __wait_on_freeing_inode fs/inode.c:2196 [inline] find_inode_fast+0x35a/0x4c0 fs/inode.c:950 iget_locked+0xb1/0x830 fs/inode.c:1273 __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861 ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389 ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148 ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880 ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296 evict+0x2a4/0x620 fs/inode.c:664 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4
4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296 evict+0x2a4/0x620 fs/inode.c:664 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [inline] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa5406fd5ea RSP: 002b:00007ffc7232f968 EFLAGS: 00000202
ommon.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa5406fd5ea RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970 RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432 R10: 0000000000804a03 R11: 0000000000000202 R12: 0000000000000004 R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 0000000000000000 </TASK> ================================================================== The problem is that the inode contains an xattr entry with ea_inum of 15 when cleaning up an orphan inode <15>. When evict inode <15>, the referenc
de contains an xattr entry with ea_inum of 15 when cleaning up an orphan inode <15>. When evict inode <15>, the reference counting of the corresponding EA inode is decreased. When EA inode <15> is found by find_inode_fast() in __ext4_iget(), it is found that the EA inode holds the I_FREEING flag and waits for the EA inode to complete deletion. As a result, when inode <15> is being deleted, we wait for inode <15> to complete the deletion, resulting in an infinite loop and triggering Hung Task. To solve this problem, we only need to check whether the ino of EA inode and parent is the same before getting EA inode. References: - https://git.kernel.org/stable/c/efddc7e106fdf8d1f62d45e79de78f63b7c
t is the same before getting EA inode. References: - https://git.kernel.org/stable/c/efddc7e106fdf8d1f62d45e79de78f63b7c04fba - https://git.kernel.org/stable/c/64b72f5e7574020dea62ab733d88a54d903c42a1 - https://git.kernel.org/stable/c/2c96c52aeaa6fd9163cfacdd98778b4a0398ef18 - https://git.kernel.org/stable/c/a98160d8f3e6242ca9b7f443f26e7ef3a61ba684 - https://git.kernel.org/stable/c/1aec41c98cce61d19ce89650895e51b9f3cdef13 - https://git.kernel.org/stable/c/94fd091576b12540924f6316ebc0678e84cb2800 - https://git.kernel.org/stable/c/73f7987fe1b82596f1a380e85cd0097ebaae7e01 - https://git.kernel.org/stable/c/0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7
CVE ID: CVE-2023-53090 State: PUBLISHED Published: 2025-05-02T15:55:36.164Z Last Updated: 2025-09-16T08:02:17.858Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix an illegal memory access In the kfd_wait_on_events() function, the kfd_event_waiter structure is allocated by alloc_event_waiters(), but the event field of the waiter structure is not initialized; When copy_from_user() fails in the kfd_wait_on_events() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function
y of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log: localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9
362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: _raw_spin_lock_irqsave+0x30/0x40 localhost kernel: remove_wait_queue+0x12/0x50 localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydc
ents+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: __x64_sys_ioctl+0x8e/0xd0 localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0 localhost kernel: do_syscall_64+0x33/0x80 localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7 Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check. References: - https://git.kernel.org/s
lloc, and remove redundant 0-initialization and a redundant loop condition check. References: - https://git.kernel.org/stable/c/5a3fb3b745af0ce46ec2e0c8e507bae45b937334 - https://git.kernel.org/stable/c/bbf5eada4334a96e3a204b2307ff5b14dc380b0b - https://git.kernel.org/stable/c/6936525142a015e854d0a23e9ad9ea0a28b3843d - https://git.kernel.org/stable/c/2fece63b55c5d74cd6f5de51159e2cde37e10555 - https://git.kernel.org/stable/c/d9923e7214a870b312bf61f6a89c7554d0966985 - https://git.kernel.org/stable/c/61f306f8df0d5559659c5578cf6d95236bcdcb25 - https://git.kernel.org/stable/c/4fc8fff378b2f2039f2a666d9f8c570f4e58352c
CVE ID: CVE-2023-53091 State: PUBLISHED Published: 2025-05-02T15:55:36.852Z Last Updated: 2025-05-04T07:49:39.059Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: update s_journal_inum if it changes after journal replay When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the
ch may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock. References: - https://git.kernel.org/stable/c/499fef2030fb754c68b1c7cb3a799a3bc1d0d925 - https://git.kernel.org/stable/c/70e66bdeae4d0f7c8e87762f425b68aedd5e8955 - https://git.kernel.org/stable/c/ee0c5277d4fab920bd31345c49e193ecede9ecef - https://git.kernel.org/stable/c/3039d8b8692408438a618fac2776b629852663c3
CVE ID: CVE-2023-53092 State: PUBLISHED Published: 2025-05-02T15:55:37.541Z Last Updated: 2025-05-04T07:49:40.424Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: interconnect: exynos: fix node leak in probe PM QoS error path Make sure to add the newly allocated interconnect node to the provider before adding the PM QoS request so that the node is freed on errors. References: - https://git.kernel.org/stable/c/fd4738ae1a0c216d25360a98e835967b06d6a253 - https://git.kernel.org/stable/c/c479e4ac4a3d1485a48599e66ce46547c1367828 - https://git.kernel.org/stable/c/b71dd43bd49bd68186c1d19dbeedee219e003149 - https://git.kernel.org/stable/
6547c1367828 - https://git.kernel.org/stable/c/b71dd43bd49bd68186c1d19dbeedee219e003149 - https://git.kernel.org/stable/c/3aab264875bf3c915ea2517fae1eec213e0b4987
CVE ID: CVE-2023-53093 State: PUBLISHED Published: 2025-05-02T15:55:38.386Z Last Updated: 2025-05-04T07:49:41.656Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Do not let histogram values have some modifiers Histogram values can not be strings, stacktraces, graphs, symbols, syscalls, or grouped in buckets or log. Give an error if a value is set to do so. Note, the histogram code was not prepared to handle these modifiers for histograms and caused a bug. Mark Rutland reported: # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitco
__arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist [ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 143.695190] Mem abort info: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: level 0 translation fault [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] use
t [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Modules linked in: [ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Hardware name: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : hist_field_name.part.0+0x14/0x140 [ 143.707504] lr : hist_field_name.part.0+0x104/0x140 [ 143.707774] sp : ffff800008
: hist_field_name.part.0+0x14/0x140 [ 143.707504] lr : hist_field_name.part.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584]
2072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Call trace: [ 143.712115] hist_field_name.part.0+0x14/0x140 [ 143.712642] hist_field_name.part.0+0x104/0x140 [ 143.712925] hist_field_print+0x28/0x140 [ 143.713125] event_hist_trigger_print+0x174/0x4d0 [ 143.713348] hist_show+0xf8/0x980 [ 143.713521] seq_read_iter+0x1bc/0x4b0 [ 143.713711] seq_read+0x8c/0xc4 [ 143.713876] vfs_read+0xc8/0
t_show+0xf8/0x980 [ 143.713521] seq_read_iter+0x1bc/0x4b0 [ 143.713711] seq_read+0x8c/0xc4 [ 143.713876] vfs_read+0xc8/0x2a4 [ 143.714043] ksys_read+0x70/0xfc [ 143.714218] __arm64_sys_read+0x24/0x30 [ 143.714400] invoke_syscall+0x50/0x120 [ 143.714587] el0_svc_common.constprop.0+0x4c/0x100 [ 143.714807] do_el0_svc+0x44/0xd0 [ 143.714970] el0_svc+0x2c/0x84 [ 143.715134] el0t_64_sync_handler+0xbc/0x140 [ 143.715334] el0t_64_sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510] ---[ end trace 0000000000000000 ]--- Segmentation fault References: - https://git.kernel.org/stable/c/39cd75f2f3a43c0e2f95749eb6dd6420c553f87d - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/39cd75f2f3a43c0e2f95749eb6dd6420c553f87d - https://git.kernel.org/stable/c/2fc0ee435c9264cdb7c5e872f76cd9bb97640227 - https://git.kernel.org/stable/c/e0213434fe3e4a0d118923dc98d31e7ff1cd9e45
CVE ID: CVE-2023-53094 State: PUBLISHED Published: 2025-05-02T15:55:39.045Z Last Updated: 2025-05-04T12:50:23.463Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: fix race on RX DMA shutdown From time to time DMA completion can come in the middle of DMA shutdown: <process ctx>: <IRQ>: lpuart32_shutdown() lpuart_dma_shutdown() del_timer_sync() lpuart_dma_rx_complete() lpuart_copy_rx_to_tty() mod_timer() lpuart_dma_rx_free() When the timer fires a bit later, sport->dma_rx_desc is NULL: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 pc : lpuart_copy_rx_to_tty+0xcc/0x5bc
able to handle kernel NULL pointer dereference at virtual address 0000000000000004 pc : lpuart_copy_rx_to_tty+0xcc/0x5bc lr : lpuart_timer_func+0x1c/0x2c Call trace: lpuart_copy_rx_to_tty lpuart_timer_func call_timer_fn __run_timers.part.0 run_timer_softirq __do_softirq __irq_exit_rcu irq_exit handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler ... To fix this fold del_timer_sync() into lpuart_dma_rx_free() after dmaengine_terminate_sync() to make sure timer will not be re-started in lpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete(). References: - https://git.kernel.org/stable/c/19a98d56dfedafb25652bdb9cd48a4e73ceba702 - https://git.kernel.org/stable/c/90530e7214c8a04dc
s://git.kernel.org/stable/c/19a98d56dfedafb25652bdb9cd48a4e73ceba702 - https://git.kernel.org/stable/c/90530e7214c8a04dcdde57502d93fa96af288c38 - https://git.kernel.org/stable/c/954fc9931f0aabf272b5674cf468affdd88d3a36 - https://git.kernel.org/stable/c/2a36b444cace9580380467fd1183bb5e85bcc80a - https://git.kernel.org/stable/c/1be6f2b15f902c02e055ae0b419ca789200473c9
CVE ID: CVE-2023-53095 State: PUBLISHED Published: 2025-05-02T15:55:39.661Z Last Updated: 2025-05-04T07:49:44.736Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource in the process of being removed from an object. The locking rules here are a bit unclear but it looks currently like res->bo assignment is protected by the LRU lock, whereas bo->resource is protected by the object lock, while *clearing* of bo->resource is also protected by the LRU lock. This means that if we check that bo->resource points to the LRU resource under the LRU lock we should be
y the LRU lock. This means that if we check that bo->resource points to the LRU resource under the LRU lock we should be safe. So perform that check before deciding to swap out a bo. That avoids dereferencing a NULL bo->resource in ttm_bo_swapout(). References: - https://git.kernel.org/stable/c/9ba1720f6c4a0f13c3f3cb5c28132ee75555d04f - https://git.kernel.org/stable/c/9d9b1f9f7a72d83ebf173534e76b246349f32374 - https://git.kernel.org/stable/c/9a9a8fe26751334b7739193a94eba741073b8a55
CVE ID: CVE-2023-53096 State: PUBLISHED Published: 2025-05-02T15:55:40.287Z Last Updated: 2025-05-04T07:49:46.113Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed. References: - https://git.kernel.org/stable/c/f1e3a20c60196c37a402c584d0c9de306ba988ce - https://git.kernel.org/stable/c/efae80ca13faa94457208852825731da44a788ad - https://git.kernel.org/stable/c/2e0b13a1827229a02abef97b50ffaf89ba25370a - https://git.kernel.org/stable/c/3167306455d0fbbbcf08cb25651acc527a86a95e - htt
e0b13a1827229a02abef97b50ffaf89ba25370a - https://git.kernel.org/stable/c/3167306455d0fbbbcf08cb25651acc527a86a95e - https://git.kernel.org/stable/c/c1722e4113281fb34e5b4fb5c5387b17cd39a537 - https://git.kernel.org/stable/c/a5904f415e1af72fa8fe6665aa4f554dc2099a95
CVE ID: CVE-2023-53097 State: PUBLISHED Published: 2025-05-02T15:55:40.928Z Last Updated: 2025-05-04T07:49:47.184Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. References: - https://git.kernel.org/stable/c/e3a62a35f903fd8be5b44542fe3901ec45f16757 - https://git.kernel.org/stable/c/24c1bd1cd0d1ff821fd7d2f01a1e648c7882dfc2 - https://git.kernel.org/sta
fe3901ec45f16757 - https://git.kernel.org/stable/c/24c1bd1cd0d1ff821fd7d2f01a1e648c7882dfc2 - https://git.kernel.org/stable/c/4050498c0ae3946c223fc63e9dd7b878b76611e0 - https://git.kernel.org/stable/c/b505063910c134778202dfad9332dfcecb76bab3
CVE ID: CVE-2023-53098 State: PUBLISHED Published: 2025-05-02T15:55:41.762Z Last Updated: 2025-05-04T07:49:48.319Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: rc: gpio-ir-recv: add remove function In case runtime PM is enabled, do runtime PM clean up to remove cpu latency qos request, otherwise driver removal may have below kernel dump: [ 19.463299] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [ 19.472161] Mem abort info: [ 19.474985] ESR = 0x0000000096000004 [ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.487149] EA = 0, S1PTW = 0 [ 19
19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.487149] EA = 0, S1PTW = 0 [ 19.490361] FSC = 0x04: level 0 translation fault [ 19.495256] Data abort info: [ 19.498149] ISV = 0, ISS = 0x00000004 [ 19.501997] CM = 0, WnR = 0 [ 19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000 [ 19.511432] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000 [ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last unloaded: rc_core] [ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (
PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT) [ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110 [ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.557294] sp : ffff800008ce3740 [ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27: ffff800008ce3d50 [ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24: ffffc7e3f9ef0e30 [ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21: 0000000000000008 [ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18: ffffffffffffffff [ 19.588570] x17