deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53074
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini

The call trace occurs when the amdgpu is removed after
the mode1 reset. During mode1 reset, from suspend to resume,
there is no need to reinitialize the ta firmware buffer
which caused the bo pin_count increase redundantly.

[  489.885525] Call Trace:
[  489.885525]  <TASK>
[  489.885526]  amdttm_bo_put+0x34/0x50 [amdttm]
[  489.885529]  amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu]
[  489.885620]  psp_free_shared_bufs+0xb7/0x150 [amdgpu]
[  489.885720]  psp_hw_fini+0xce/0x170 [amdgpu]
[  489.885815]  amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu]
[  489.885960]  ? blocking_notifier_chain_unregister+0x56/0xb0
[  489.885962]  amdgpu_driver_unload_kms+0x51/0x60 [amdgpu]
[  489.886049]  amdgpu_pci_remove+0x5a/0x140 [amdgpu]
[  489.886132]  ? __pm_runtime_resume+0x60/0x90
[  489.886134]  pci_device_remove+0x3e/0xb0
[  489.886135]  __device_release_driver+0x1ab/0x2a0
[  489.886137]  driver_detach+0xf3/0x140
[  489.886138]  bus_remove_driver+0x6c/0xf0
[  489.886140]  driver_unregister+0x31/0x60
[  489.886141]  pci_unregister_driver+0x40/0x90
[  489.886142]  amdgpu_exit+0x15/0x451 [amdgpu]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/23f4a2d29ba57bf88095f817de5809d427fcbe7e; https://git.kernel.org/stable/c/55a7c647ebf6e376c45d8322568dd6eb71937139; https://git.kernel.org/stable/c/7be9a2f8c5179520a7d5570e648e0c97d09e4fae
CVE: CVE-2023-53075
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

ftrace: Fix invalid address access in lookup_rec() when index is 0

KASAN reported follow problem:

 BUG: KASAN: use-after-free in lookup_rec
 Read of size 8 at addr ffff000199270ff0 by task modprobe
 CPU: 2 Comm: modprobe
 Call trace:
  kasan_report
  __asan_load8
  lookup_rec
  ftrace_location
  arch_check_ftrace_location
  check_kprobe_address_safe
  register_kprobe

When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a
pg which is newly added to ftrace_pages_start in ftrace_process_locs().
Before the first pg->index++, index is 0 and accessing pg->records[-1].ip
will cause this problem.

Don't check the ip when pg->index is 0.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2a0d71fabfeb349216d33f001a6421b1768bd3a9; https://git.kernel.org/stable/c/2de28e5ce34b22b73b833a21e2c45ae3aade3964; https://git.kernel.org/stable/c/4f84f31f63416b0f02fc146ffdc4ab32723eb7e8
CVE: CVE-2023-53076
Published: 2025-05-02
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53077
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes

[WHY]
When PTEBufferSizeInRequests is zero, UBSAN reports the following
warning because dml_log2 returns an unexpected negative value:

  shift exponent[PII_REDACTED] is too large for 32-bit type 'int'

[HOW]

In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and
assign the result directly.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/031f196d1b1b6d5dfcb0533b431e3ab1750e6189; https://git.kernel.org/stable/c/7257070be70e19a9138f39009c1a26c83a8a7cfa; https://git.kernel.org/stable/c/a16394b5d661afec9a264fecac3abd87aea439ea
CVE: CVE-2023-53078
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()

If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
freed, which will cause following memleak:

unreferenced object 0xffff88810b2c6980 (size 32):
  comm "kworker/u16:2", pid 635322, jiffies[PII_REDACTED] (age 1216426.076s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff  @9$.............
  backtrace:
    [<[PII_REDACTED]f3a26d>] alua_activate+0xb0/0x320
    [<000000003b529641>] scsi_dh_activate+0xb2/0x140
    [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]
    [<000000007adc9ace>] process_one_work+0x3c5/0x730
    [<00000000c457a985>] worker_thread+0x93/0x650
    [<00000000cb80e628>] kthread+0x1ba/0x210
    [<00000000a1e61077>] ret_from_fork+0x22/0x30

Fix the problem by freeing 'qdata' in error path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0d89254a4320eb7de0970c478172f764125c6355; https://git.kernel.org/stable/c/123483df146492ca22b503ae6dacc2ce7c3a3974; https://git.kernel.org/stable/c/1c55982beb80c7d3c30278fc6cfda8496a31dbe6
CVE: CVE-2023-53079
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix steering rules cleanup

vport's mc, uc and multicast rules are not deleted in teardown path when
EEH happens. Since the vport's promisc settings(uc, mc and all) in
firmware are reset after EEH, mlx5 driver will try to delete the above
rules in the initialization path. This cause kernel crash because these
software rules are no longer valid.

Fix by nullifying these rules right after delete to avoid accessing any dangling
pointers.

Call Trace:
__list_del_entry_valid+0xcc/0x100 (unreliable)
tree_put_node+0xf4/0x1b0 [mlx5_core]
tree_remove_node+0x30/0x70 [mlx5_core]
mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core]
esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core]
esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core]
esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core]
esw_enable_vport+0x130/0x260 [mlx5_core]
mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core]
mlx5_device_enable_sriov+0x74/0x440 [mlx5_core]
mlx5_load_one+0x114c/0x1550 [mlx5_core]
mlx5_pci_resume+0x68/0xf0 [mlx5_core]
eeh_report_resume+0x1a4/0x230
eeh_pe_dev_traverse+0x98/0x170
eeh_handle_normal_event+0x3e4/0x640
eeh_handle_event+0x4c/0x370
eeh_event_handler+0x14c/0x210
kthread+0x168/0x1b0
ret_from_kernel_thread+0x5c/0x84
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/18cead61e437f4c7898acca0a5f3df12f801d97f; https://git.kernel.org/stable/c/4df1f2d36bdc9a368650bf14b9097c555e95f71d; https://git.kernel.org/stable/c/63546395a0e6ac264f78f65218086ce6014b4494
CVE: CVE-2023-53080
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

xsk: Add missing overflow check in xdp_umem_reg

The number of chunks can overflow u32. Make sure to return -EINVAL on
overflow. Also remove a redundant u32 cast assigning umem->npgs.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3cfc3564411acf96bf2fb791f706a1aa4f872c1d; https://git.kernel.org/stable/c/580634b03a55f04a3c1968bcbd97736c079c6601; https://git.kernel.org/stable/c/a069909acc4435eeb41d05ccc03baa447cc01b7e
CVE: CVE-2023-53081
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix data corruption after failed write

When buffered write fails to copy data into underlying page cache page,
ocfs2_write_end_nolock() just zeroes out and dirties the page.  This can
leave dirty page beyond EOF and if page writeback tries to write this page
before write succeeds and expands i_size, page gets into inconsistent
state where page dirty bit is clear but buffer dirty bits stay set
resulting in page data never getting written and so data copied to the
page is lost.  Fix the problem by invalidating page beyond EOF after
failed write.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1629f6f522b2d[PII_REDACTED]66a84b240683bbee3; https://git.kernel.org/stable/c/205759c6c18f54659b0b5976b14a52d1b3eb9f57; https://git.kernel.org/stable/c/47eb055ad3588fc96d34e9e1dd87b210ce62906b
CVE: CVE-2023-53083
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

nfsd: don't replace page in rq_pages if it's a continuation of last page

The splice read calls nfsd_splice_actor to put the pages containing file
data into the svc_rqst->rq_pages array. It's possible however to get a
splice result that only has a partial page at the end, if (e.g.) the
filesystem hands back a short read that doesn't cover the whole page.

nfsd_splice_actor will plop the partial page into its rq_pages array and
return. Then later, when nfsd_splice_actor is called again, the
remainder of the page may end up being filled out. At this point,
nfsd_splice_actor will put the page into the array _again_ corrupting
the reply. If this is done enough times, rq_next_page will overrun the
array and corrupt the trailing fields -- the rq_respages and
rq_next_page pointers themselves.

If we've already added the page to the array in the last pass, don't add
it to the array a second time when dealing with a splice continuation.
This was originally handled properly in nfsd_splice_actor, but commit
91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check
for it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0101067f376eb7b9afd00279270f25d5111a091d; https://git.kernel.org/stable/c/12eca509234acb6b666802edf77408bb70d7bfca; https://git.kernel.org/stable/c/27c934dd8832dd40fd34776f916dc201e18b319b
CVE: CVE-2023-53084
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/shmem-helper: Remove another errant put in error path

drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
in the dma-buf shmem GEM object getting prematurely freed leading to a
later use-after-free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5cfb617967b05f8f27e862c97db1fabd8485f4db; https://git.kernel.org/stable/c/684c7372bbd6447c2e86a2a84e97a1478604d21f; https://git.kernel.org/stable/c/77d26c824aa5a7e0681ef1d5b75fe538d746addc
CVE: CVE-2023-53085
Published: 2025-05-02
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/edid: fix info leak when failing to get panel id

Make sure to clear the transfer buffer before fetching the EDID to
avoid leaking slab data to the logs on errors that leave the buffer
unchanged.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/4d8457fe0eb9c80ff7795cf8a30962128b71d853; https://git.kernel.org/stable/c/598c42c78919117dc0d235ae22d17ad642377483
CVE: CVE-2023-53088
Published: 2025-05-02
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 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_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 commit depends on the two parent ones:

  mptcp: refactor passive socket initialization
  mptcp: use the workqueue to destroy unaccepted sockets
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0a3f4f1f9c27215e4ddcd312558342e57b93e518; https://git.kernel.org/stable/c/0f4f4cf5d32f10543deb946a37111e714579511e; https://git.kernel.org/stable/c/5564be74a22a61855f8b8c100d8c4abb003bb792
CVE: CVE-2023-53089
Published: 2025-05-02
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: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/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 ORIG_RAX:[PII_REDACTED]0000a5
RAX: ffffffffffffffda RBX: [PII_REDACTED] RCX: 00007fa5406fd5ea
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: 00007ffc7232f970
RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: [PII_REDACTED]
R10:[PII_REDACTED]804a03 R11: [PII_REDACTED] R12: [PII_REDACTED]
R13:[PII_REDACTED]a7a2c0 R14: 00007ffc7232f9b0 R15: [PII_REDACTED]
 </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 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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7; https://git.kernel.org/stable/c/1aec41c98cce61d19ce89650895e51b9f3cdef13; https://git.kernel.org/stable/c/2c96c52aeaa6fd9163cfacdd98778b4a0398ef18
CVE: CVE-2023-53090
Published: 2025-05-02
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, 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: [PII_REDACTED] RCX:[PII_REDACTED]2c0000
localhost kernel: RDX: ffff9e855eeacb80 RSI:[PII_REDACTED]00279c RDI: ffffe7088f6a21d0
localhost kernel: RBP: ffffe7088f6a21d0 R08:[PII_REDACTED]2c0000 R09: ffffaa53c362be64
localhost kernel: R10: ffffaa53c362bbd8 R11: [PII_REDACTED] R12: [PII_REDACTED]
localhost kernel: R13: ffff9e7ead15d600 R14: [PII_REDACTED] R15: ffff9e7ead15d698
localhost kernel: FS:  0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:[PII_REDACTED]
localhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
localhost kernel: CR2: [PII_REDACTED] CR3: 000000044d7a4000 CR4:[PII_REDACTED]3506e0
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 [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.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/2fece63b55c5d74cd6f5de51159e2cde37e10555; https://git.kernel.org/stable/c/4fc8fff378b2f2039f2a666d9f8c570f4e58352c; https://git.kernel.org/stable/c/5a3fb3b745af0ce46ec2e0c8e507bae45b937334
CVE: CVE-2023-53091
Published: 2025-05-02
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 change, and rewrite the
current journal_inum to the superblock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3039d8b[PII_REDACTED]a618fac2776b629852663c3; https://git.kernel.org/stable/c/499fef2030fb754c68b1c7cb3a799a3bc1d0d925; https://git.kernel.org/stable/c/70e66bdeae4d0f7c8e87762f425b68aedd5e8955
CVE: CVE-2023-53092
Published: 2025-05-02
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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3aab264875bf3c915ea2517fae1eec213e0b4987; https://git.kernel.org/stable/c/b71dd43bd49bd68186c1d19dbeedee219e003149; https://git.kernel.org/stable/c/c479e4ac4a3d1485a48599e66ce46547c1367828
CVE: CVE-2023-53094
Published: 2025-05-02
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 [PII_REDACTED]
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().
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/19a98d56dfedafb25652bdb9cd48a4e73ceba702; https://git.kernel.org/stable/c/1be6f2b15f902c02e055ae0b419ca789200473c9; https://git.kernel.org/stable/c/2a36b444cace[PII_REDACTED]fd1183bb5e85bcc80a
CVE: CVE-2023-53095
Published: 2025-05-02
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 safe.
So perform that check before deciding to swap out a bo. That avoids
dereferencing a NULL bo->resource in ttm_bo_swapout().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/9a9a8fe26751334b7739193a94eba741073b8a55; https://git.kernel.org/stable/c/9ba1720f6c4a0f13c3f3cb5c28132ee75555d04f; https://git.kernel.org/stable/c/9d9b1f9f7a72d83ebf173534e76b246349f32374
CVE: CVE-2023-53096
Published: 2025-05-02
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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2e0b13a1827229a02abef97b50ffaf89ba25370a; https://git.kernel.org/stable/c/[PII_REDACTED]d0fbbbcf08cb25651acc527a86a95e; https://git.kernel.org/stable/c/a5904f415e1af72fa8fe6665aa4f554dc2099a95
CVE: CVE-2023-53097
Published: 2025-05-02
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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/24c1bd1cd0d1ff821fd7d2f01a1e648c7882dfc2; https://git.kernel.org/stable/c/4050498c0ae3946c223fc63e9dd7b878b76611e0; https://git.kernel.org/stable/c/b505063910c134778202dfad9332dfcecb76bab3