deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53221
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix memleak due to fentry attach failure

If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.

This meamleak can be verified by a simple bpf program as follows:

  SEC("fentry/trap_init")
  int fentry_run()
  {
      return 0;
  }

It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.

  $ tail /proc/kallsyms
  ffffffffc0613000 t bpf_trampoline_[PII_REDACTED]_1  [bpf]
  ffffffffc06c3000 t bpf_trampoline_[PII_REDACTED]_1  [bpf]

  $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'"
  [2522] FUNC 'trap_init' type_id=119 linkage=static

  $ echo $([PII_REDACTED] & 0x7fffffff))
  2522

Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/108598c39eefbedc9882273ac0df96127a629220; https://git.kernel.org/stable/c/20109ddd5bea2c24d790debf5d02584ef24c3f5e; https://git.kernel.org/stable/c/6aa27775db63ba8c7c73891c7dfb71ddc230c48d
CVE: CVE-2023-53222
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: jfs_dmap: Validate db_l2nbperpage while mounting

In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block
number inside dbFree(). db_l2nbperpage, which is the log2 number of
blocks per page, is passed as an argument to BLKTODMAP which uses it
for shifting.

Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is
too big. This happens because the large value is set without any
validation in dbMount() at line 181.

Thus, make sure that db_l2nbperpage is correct while mounting.

Max number of blocks per page = Page size / Min block size
=> log2(Max num_block per page) = log2(Page size / Min block size)
				= log2(Page size) - log2(Min block size)

=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/11509910c599cbd04585ec35a6d5e1a0053d84c1; https://git.kernel.org/stable/c/2a03c4e683d33d17b667418eb717b13dda1fac6b; https://git.kernel.org/stable/c/47b7eaae08e8b2f25bdf37bc14d21be090bcb20f
CVE: CVE-2023-53223
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dsi: Add missing check for alloc_ordered_workqueue

Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference.

Patchwork: https://patchwork.freedesktop.org/patch/517646/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/115906ca7b535afb1fe7b5406c566ccd3873f82b; https://git.kernel.org/stable/c/25a6499b1a53d854eda2b161b5c8a20296515dbe; https://git.kernel.org/stable/c/3a9a4a9725c60f04326b5019a52ce15aee808506
CVE: CVE-2023-53224
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: Fix function prototype mismatch for ext4_feat_ktype

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed.

ext4_feat_ktype was setting the "release" handler to "kfree", which
doesn't have a matching function prototype. Add a simple wrapper
with the correct prototype.

This was found as a result of Clang's new -Wcast-function-type-strict
flag, which is more sensitive than the simpler -Wcast-function-type,
which only checks for type width mismatches.

Note that this code is only reached when ext4 is a loadable module and
it is being unloaded:

 CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)
 ...
 RIP: 0010:kobject_put+0xbb/0x1b0
 ...
 Call Trace:
  <TASK>
  ext4_exit_sysfs+0x14/0x60 [ext4]
  cleanup_module+0x67/0xedb [ext4]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0a1394e07c5d6bf1bfc25db8589ff1b1bfb6f46a; https://git.kernel.org/stable/c/118901ad1f25d2334255b3d50512fa20591531cd; https://git.kernel.org/stable/c/1ba10d3640e9783dad811fe4e24d55465c37c64d
CVE: CVE-2023-53225
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: imx: Don't skip cleanup in remove's error path

Returning early in a platform driver's remove callback is wrong. In this
case the dma resources are not released in the error path. this is never
retried later and so this is a permanent leak. To fix this, only skip
hardware disabling if waking the device fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/11951c9e3f364d7ae3b568a0e52c8335d43066b5; https://git.kernel.org/stable/c/57a463226638f1ceabbb029cbd21b0c94640f1b5; https://git.kernel.org/stable/c/6d16305a1535873e0a8a8ae92ea2d9106ec2d7df
CVE: CVE-2023-53226
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Fix OOB and integer underflow when rx packets

Make sure mwifiex_process_mgmt_packet,
mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,
mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet
not out-of-bounds access the skb->data buffer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191, CWE-191
References: https://git.kernel.org/stable/c/[PII_REDACTED]731c58e105b501ed60b83a91ea941; https://git.kernel.org/stable/c/29eca8b7863d1d7de6c5b746b374e3487d14f154; https://git.kernel.org/stable/c/3975e21d4d01efaf0296ded40d11c06589c49245
CVE: CVE-2023-53227
Published: 2025-09-15
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53228
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: drop redundant sched job cleanup when cs is aborted

Once command submission failed due to userptr invalidation in
amdgpu_cs_submit, legacy code will perform cleanup of scheduler
job. However, it's not needed at all, as former commit has integrated
job cleanup stuff into amdgpu_job_free. Otherwise, because of double
free, a NULL pointer dereference will occur in such scenario.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1253685f0d3eb3eab0bfc4bf15ab341a5f3da0c8; https://git.kernel.org/stable/c/c1564d4b105ae535eb3183ecaaa987685b20a888; https://git.kernel.org/stable/c/cdce1644d85e858c68fb5fa67d78eb1035bf34f4
CVE: CVE-2023-53229
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta

Avoid potential data corruption issues caused by uninitialized driver
private data structures.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/022c8320d9eb7394538bd716fa1a07a5ed92621b; https://git.kernel.org/stable/c/12b220a6171faf10638ab683a975cadcf1a352d6; https://git.kernel.org/stable/c/30c5a016a37a668c1c07442cf94de6e99ea7417a
CVE: CVE-2023-53230
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix warning in cifs_smb3_do_mount()

This fixes the following warning reported by kernel test robot

  fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible
  memory leak of 'cifs_sb'
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/12c30f33cc6769bf411088a2872843c4f9ea32f9; https://git.kernel.org/stable/c/945f4a7aff84fde1f825d17a[PII_REDACTED]da3228; https://git.kernel.org/stable/c/[PII_REDACTED]674361f455ea8901375cff5b800be5
CVE: CVE-2023-53231
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: Fix detection of atomic context

Current check for atomic context is not sufficient as
z_erofs_decompressqueue_endio can be called under rcu lock
from blk_mq_flush_plug_list(). See the stacktrace [1]

In such case we should hand off the decompression work for async
processing rather than trying to do sync decompression in current
context. Patch fixes the detection by checking for
rcu_read_lock_any_held() and while at it use more appropriate
!in_task() check than in_atomic().

Background: Historically erofs would always schedule a kworker for
decompression which would incur the scheduling cost regardless of
the context. But z_erofs_decompressqueue_endio() may not always
be in atomic context and we could actually benefit from doing the
decompression in z_erofs_decompressqueue_endio() if we are in
thread context, for example when running with dm-verity.
This optimization was later added in patch [2] which has shown
improvement in performance benchmarks.

==============================================
[1] Problem stacktrace
[name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291
[name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi
[name:core&]preempt_count: 0, expected: 0
[name:core&]RCU nest depth: 1, expected: 0
CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S      W  OE      6.1.25-android14-5-maybe-dirty-mainline #1
Hardware name: MT6897 (DT)
Call trace:
 dump_backtrace+0x108/0x15c
 show_stack+0x20/0x30
 dump_stack_lvl+0x6c/0x8c
 dump_stack+0x20/0x48
 __might_resched+0x1fc/0x308
 __might_sleep+0x50/0x88
 mutex_lock+0x2c/0x110
 z_erofs_decompress_queue+0x11c/0xc10
 z_erofs_decompress_kickoff+0x110/0x1a4
 z_erofs_decompressqueue_endio+0x154/0x180
 bio_endio+0x1b0/0x1d8
 __dm_io_complete+0x22c/0x280
 clone_endio+0xe4/0x280
 bio_endio+0x1b0/0x1d8
 blk_update_request+0x138/0x3a4
 blk_mq_plug_issue_direct+0xd4/0x19c
 blk_mq_flush_plug_list+0x2b0/0x354
 __blk_flush_plug+0x110/0x160
 blk_finish_plug+0x30/0x4c
 read_pages+0x2fc/0x370
 page_cache_ra_unbounded+0xa4/0x23c
 page_cache_ra_order+0x290/0x320
 do_sync_mmap_readahead+0x108/0x2c0
 filemap_fault+0x19c/0x52c
 __do_fault+0xc4/0x114
 handle_mm_fault+0x5b4/0x1168
 do_page_fault+0x338/0x4b4
 do_translation_fault+0x40/0x60
 do_mem_abort+0x60/0xc8
 el0_da+0x4c/0xe0
 el0t_64_sync_handler+0xd4/0xfc
 el0t_64_sync+0x1a0/0x1a4

[2] Link: https://lore.kernel.org/all/[PII_REDACTED]5448.13921-1-huangjianan@oppo.com/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/12d0a24afd9ea58e581ea64d64e066f2027b28d9; https://git.kernel.org/stable/c/597fb60c[PII_REDACTED]7e173b75cab8f6eb1ca657
CVE: CVE-2023-53232
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data

The MT7921 driver no longer uses eeprom.data, but the relevant code has not
been removed completely since
commit 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability").
This could result in potential invalid memory access.

To fix the kernel panic issue in mt7921, it is necessary to avoid accessing
unallocated eeprom.data which can lead to invalid memory access.

Furthermore, it is possible to entirely eliminate the
mt7921_mcu_parse_eeprom function and solely depend on
mt7921_mcu_parse_response to divide the RxD header.

[2.702735] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[2.702740] #PF: supervisor write access in kernel mode
[2.702741] #PF: error_code(0x0002) - not-present page
[2.702743] PGD 0 P4D 0
[2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI
[2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common]
[2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286
[2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: [PII_REDACTED]
[2.702762] RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffffa367cc7bf500
[2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: [PII_REDACTED]
[2.702764] R10: [PII_REDACTED] R11: ffffffffc04702e4 R12: ffffa367e8329f40
[2.702766] R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffffa367e8329f40
[2.702768] FS:  000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:[PII_REDACTED]
[2.702769] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[2.702775] CR2: [PII_REDACTED] CR3:[PII_REDACTED]3c6004 CR4:[PII_REDACTED]770ee0
[2.702776] PKRU: 55555554
[2.702777] Call Trace:
[2.702782]  mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76 <HASH:1bc4 5>]
[2.702785]  mt7921_run_firmware+0x241/0x853 [mt7921_common <HASH:6a2f 6>]
[2.702789]  mt7921e_mcu_init+0x2b/0x56 [mt7921e <HASH:d290 7>]
[2.702792]  mt7921_register_device+0x2eb/0x5a5 [mt7921_common <HASH:6a2f 6>]
[2.702795]  ? mt7921_irq_tasklet+0x1d4/0x1d4 [mt7921e <HASH:d290 7>]
[2.702797]  mt7921_pci_probe+0x2d6/0x319 [mt7921e <HASH:d290 7>]
[2.702799]  pci_device_probe+0x9f/0x12a
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/11181b6c8641cd417935b76ea997d0169f2db262; https://git.kernel.org/stable/c/12db28c3ef31f719bd18fa186a40bb152e6a527c; https://git.kernel.org/stable/c/c8ba6780c65f681d217de79e17d63d5d538a239f
CVE: CVE-2023-53234
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

watchdog: Fix kmemleak in watchdog_cdev_register

kmemleak reports memory leaks in watchdog_dev_register, as follows:
unreferenced object 0xffff[PII_REDACTED]00 (size 2048):
  comm ""modprobe"", pid 28147, jiffies[PII_REDACTED] (age 61.741s)
  hex dump (first 32 bytes):
    80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff  .........0#.....
    08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00  .0#.............
  backtrace:
    [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220
    [<000000006a389304>] kmalloc_trace+0x21/0x110
    [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog]
    [<[PII_REDACTED]c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog]
    [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog]
    [<000000001f730178>] 0xffffffffc10880ae
    [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0
    [<00000000b98be325>] do_init_module+0x1ca/0x5f0
    [<[PII_REDACTED]d08e7c>] load_module+0x6133/0x70f0
    ...

unreferenced object 0xffff888105b9fa80 (size 16):
  comm ""modprobe"", pid 28147, jiffies[PII_REDACTED] (age 61.741s)
  hex dump (first 16 bytes):
    77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff  watchdog1.......
  backtrace:
    [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220
    [<[PII_REDACTED]6ab89b>] __kmalloc_node_track_caller+0x44/0x1b0
    [<000000005a39aab0>] kvasprintf+0xb5/0x140
    [<[PII_REDACTED]806f85>] kvasprintf_const+0x55/0x180
    [<[PII_REDACTED]76cb7f>] kobject_set_name_vargs+0x56/0x150
    [<00000000a92e820b>] dev_set_name+0xab/0xe0
    [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog]
    [<[PII_REDACTED]c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog]
    [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog]
    [<000000001f730178>] 0xffffffffc10880ae
    [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0
    [<00000000b98be325>] do_init_module+0x1ca/0x5f0
    [<[PII_REDACTED]d08e7c>] load_module+0x6133/0x70f0
    ...

The reason is that put_device is not be called if cdev_device_add fails
and wdd->id != 0.

watchdog_cdev_register
  wd_data = kzalloc                             [1]
  err = dev_set_name                            [2]
  ..
  err = cdev_device_add
  if (err) {
    if (wdd->id == 0) {  // wdd->id != 0
      ..
    }
    return err;  // [1],[2] would be leaked

To fix it, call put_device in all wdd->id cases.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/13721a2ac66b246f5802ba1b75ad8637e53eeecc; https://git.kernel.org/stable/c/23cc41c3f19c4d858c3708f1c0a06e94958e6c3b; https://git.kernel.org/stable/c/50808d034e199fe3ff7a9d2068a4eebeb6b4098a
CVE: CVE-2023-53236
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: Do not corrupt the pfn list when doing batch carry

If batch->end is 0 then setting npfns[0] before computing the new value of
pfns will fail to adjust the pfn and result in various page accounting
corruptions. It should be ordered after.

This seems to result in various kinds of page meta-data corruption related
failures:

  WARNING: CPU: 1 PID: 527 at mm/gup.c:75 try_grab_folio+0x503/0x740
  Modules linked in:
  CPU: 1 PID: 527 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
  RIP: 0010:try_grab_folio+0x503/0x740
  Code: e3 01 48 89 de e8 6d c1 dd ff 48 85 db 0f 84 7c fe ff ff e8 4f bf dd ff 49 8d 47 ff 48 89 45 d0 e9 73 fe ff ff e8 3d bf dd ff <0f> 0b 31 db e9 d0 fc ff ff e8 2f bf dd ff 48 8b 5d c8 31 ff 48 89
  RSP: 0018:ffffc90000f37908 EFLAGS: 00010046
  RAX: [PII_REDACTED] RBX: 00000000fffffc02 RCX: ffffffff81504c26
  RDX: [PII_REDACTED] RSI: ffff88800d030000 RDI: [PII_REDACTED]
  RBP: ffffc90000f37948 R08:[PII_REDACTED]03ca24 R09: [PII_REDACTED]
  R10:[PII_REDACTED]03ca00 R11: [PII_REDACTED] R12: ffffea000035d540
  R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffffea000035d540
  FS:  00007fecbf659740(0000) GS:ffff88807dd00000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2:[PII_REDACTED]0011c3 CR3: 000000000ef66006 CR4:[PII_REDACTED]770ee0
  PKRU: 55555554
  Call Trace:
   <TASK>
   internal_get_user_pages_fast+0xd32/0x2200
   pin_user_pages_fast+0x65/0x90
   pfn_reader_user_pin+0x376/0x390
   pfn_reader_next+0x14a/0x7b0
   pfn_reader_first+0x140/0x1b0
   iopt_area_fill_domain+0x74/0x210
   iopt_table_add_domain+0x30e/0x6e0
   iommufd_device_selftest_attach+0x7f/0x140
   iommufd_test+0x10ff/0x16f0
   iommufd_fops_ioctl+0x206/0x330
   __x64_sys_ioctl+0x10e/0x160
   do_syscall_64+0x3b/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/13a0d1ae7ee6b438f5537711a8c60cba00554943; https://git.kernel.org/stable/c/6ed5784526ddc0fb58b1798af36ec0c3139a8dca
CVE: CVE-2023-53237
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini

The gmc.ecc_irq is enabled by firmware per IFWI setting,
and the host driver is not privileged to enable/disable
the interrupt. So, it is meaningless to use the amdgpu_irq_put
function in gmc_v11_0_hw_fini, which also leads to the call
trace.

[  102.980303] Call Trace:
[  102.980303]  <TASK>
[  102.980304]  gmc_v11_0_hw_fini+0x54/0x90 [amdgpu]
[  102.980357]  gmc_v11_0_suspend+0xe/0x20 [amdgpu]
[  102.980409]  amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu]
[  102.980459]  amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]
[  102.980520]  amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu]
[  102.980573]  amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu]
[  102.980687]  amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]
[  102.980740]  process_one_work+0x21f/0x3f0
[  102.980741]  worker_thread+0x200/0x3e0
[  102.980742]  ? process_one_work+0x3f0/0x3f0
[  102.980743]  kthread+0xfd/0x130
[  102.980743]  ? kthread_complete_and_exit+0x20/0x20
[  102.980744]  ret_from_fork+0x22/0x30
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02e6cb9b3aeffc6b0e3955f6e0346293e2415cbc; https://git.kernel.org/stable/c/13af556104fa93b1945c70bbf8a0a62cd2c92879; https://git.kernel.org/stable/c/396401bc035ff5bf0c7b29c67caa10040eb3fb62
CVE: CVE-2023-53238
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe()

The size of array 'priv->ports[]' is INNO_PHY_PORT_NUM.

In the for loop, 'i' is used as the index for array 'priv->ports[]'
with a check (i > INNO_PHY_PORT_NUM) which indicates that
INNO_PHY_PORT_NUM is allowed value for 'i' in the same loop.

This > comparison needs to be changed to >=, otherwise it potentially leads
to an out of bounds write on the next iteration through the loop
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/01cb355bb92e8fcf8306e11a4774d610c5864e39; https://git.kernel.org/stable/c/13c088cf3657d70893d75cf116be937f1509cc0f; https://git.kernel.org/stable/c/195e806b2afb0bad6470c9094f7e45e0cf109ee0
CVE: CVE-2023-53239
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/mdp5: Add check for kzalloc

As kzalloc may fail and return NULL pointer,
it should be better to check the return value
in order to avoid the NULL pointer dereference.

Patchwork: https://patchwork.freedesktop.org/patch/514154/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/13fcfcb2a9a4787fe4e49841d728f6f2e9fa6911; https://git.kernel.org/stable/c/37ff771ed008b9cbffd0eab[PII_REDACTED]4694ce3; https://git.kernel.org/stable/c/3975ea6eaffe26aec634b5c473e51dc76e73af62
CVE: CVE-2023-53241
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

nfsd: call op_release, even when op_func returns an error

For ops with "trivial" replies, nfsd4_encode_operation will shortcut
most of the encoding work and skip to just marshalling up the status.
One of the things it skips is calling op_release. This could cause a
memory leak in the layoutget codepath if there is an error at an
inopportune time.

Have the compound processing engine always call op_release, even when
op_func sets an error in op->status. With this change, we also need
nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL
on error to avoid a double free.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/15a8b55dbb1ba154d82627547c5761cac884d810; https://git.kernel.org/stable/c/3d0dcada384af22dec764c8374a2997870ec86ae; https://git.kernel.org/stable/c/65a33135e91e6dd661ecdf1194b9d90c49ae3570
CVE: CVE-2023-53242
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal/drivers/hisi: Drop second sensor hi3660

The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm
allocators") exposes a panic "BRK handler: Fatal exception" on the
hi3660_thermal_probe funciton.
This is because the function allocates memory for only one
sensors array entry, but tries to fill up a second one.

Fix this by removing the unneeded second access.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/15cc25829a97c3957e520e971868aacc84341317; https://git.kernel.org/stable/c/3cf2181e438f43ed24e12424fe36d156cca233b9; https://git.kernel.org/stable/c/68e675a9b69cfc34dd915d91a4650e3ee53421f4
CVE: CVE-2023-53244
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish

When the driver calls tw68_risc_buffer() to prepare the buffer, the
function call dma_alloc_coherent may fail, resulting in a empty buffer
buf->cpu. Later when we free the buffer or access the buffer, null ptr
deref is triggered.

This bug is similar to the following one:
https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71.

We believe the bug can be also dynamically triggered from user side.
Similarly, we fix this by checking the return value of tw68_risc_buffer()
and the value of buf->cpu before buffer free.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1634b7adcc5bef645b3666fdd564e5952a9e24e0; https://git.kernel.org/stable/c/3715c5e9a8f96b6ed0dcbea06da443efccac1ecc; https://git.kernel.org/stable/c/3c67f49a6643d973e83968ea35806c7b5ae68b56