deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-54059
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: mediatek: mtk-svs: Enable the IRQ later

If the system does not come from reset (like when is booted via
kexec()), the peripheral might triger an IRQ before the data structures
are initialised.


[    0.227710] Unable to handle kernel NULL pointer dereference at virtual address[PII_REDACTED]000f08
[    0.227913] Call trace:
[    0.227918]  svs_isr+0x8c/0x538
References: https://git.kernel.org/stable/c/66ea96629bbccf1b483be506f3daff754069cdd3; https://git.kernel.org/stable/c/6b99ebd30d65ee5ab8e8dd1d378550911eff5e4f; https://git.kernel.org/stable/c/b74952aba6c3f47e7f2c5165abaeefa44c377140
CVE: CVE-2023-54060
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: Set end correctly when doing batch carry

Even though the test suite covers this it somehow became obscured that
this wasn't working.

The test iommufd_ioas.mock_domain.access_domain_destory would blow up
rarely.

end should be set to 1 because this just pushed an item, the carry, to the
pfns list.

Sometimes the test would blow up with:

  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP
  CPU: 5 PID: 584 Comm: iommufd Not tainted 6.5.0-rc1-dirty #1236
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
  RIP: 0010:batch_unpin+0xa2/0x100 [iommufd]
  Code: 17 48 81 fe ff ff 07 00 77 70 48 8b 15 b7 be 97 e2 48 85 d2 74 14 48 8b 14 fa 48 85 d2 74 0b 40 0f b6 f6 48 c1 e6 04 48 01 f2 <48> 8b 3a 48 c1 e0 06 89 ca 48 89 de 48 83 e7 f0 48 01 c7 e8 96 dc
  RSP: 0018:ffffc90001677a58 EFLAGS: 00010246
  RAX: 00007f7e2646f000 RBX: [PII_REDACTED] RCX: [PII_REDACTED]
  RDX: [PII_REDACTED] RSI: 00000000fefc4c8d RDI:[PII_REDACTED]fefc4c
  RBP: ffffc90001677a80 R08: [PII_REDACTED] R09: [PII_REDACTED]
  R10:[PII_REDACTED]030b98 R11: ffffffff81f3bb40 R12: [PII_REDACTED]
  R13: ffff888101f75800 R14: ffffc90001677ad0 R15:[PII_REDACTED]0001fe
  FS:  00007f[PII_REDACTED](0000) GS:ffff8881ba540000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: [PII_REDACTED] CR3:[PII_REDACTED]ede003 CR4:[PII_REDACTED]3706a0
  DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
  DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
  Call Trace:
   <TASK>
   ? show_regs+0x5c/0x70
   ? __die+0x1f/0x60
   ? page_fault_oops+0x15d/0x440
   ? lock_release+0xbc/0x240
   ? exc_page_fault+0x4a4/0x970
   ? asm_exc_page_fault+0x27/0x30
   ? batch_unpin+0xa2/0x100 [iommufd]
   ? batch_unpin+0xba/0x100 [iommufd]
   __iopt_area_unfill_domain+0x198/0x430 [iommufd]
   ? __mutex_lock+0x8c/0xb80
   ? __mutex_lock+0x6aa/0xb80
   ? xa_erase+0x28/0x30
   ? iopt_table_remove_domain+0x162/0x320 [iommufd]
   ? lock_release+0xbc/0x240
   iopt_area_unfill_domain+0xd/0x10 [iommufd]
   iopt_table_remove_domain+0x195/0x320 [iommufd]
   iommufd_hw_pagetable_destroy+0xb3/0x110 [iommufd]
   iommufd_object_destroy_user+0x8e/0xf0 [iommufd]
   iommufd_device_detach+0xc5/0x140 [iommufd]
   iommufd_selftest_destroy+0x1f/0x70 [iommufd]
   iommufd_object_destroy_user+0x8e/0xf0 [iommufd]
   iommufd_destroy+0x3a/0x50 [iommufd]
   iommufd_fops_ioctl+0xfb/0x170 [iommufd]
   __x64_sys_ioctl+0x40d/0x9a0
   do_syscall_64+0x3c/0x80
   entry_SYSCALL_64_after_hwframe+0x46/0xb0
References: https://git.kernel.org/stable/c/176f36a376c417b58d19f79edfce20db9317eaa2; https://git.kernel.org/stable/c/b7c822fa6b7701b17e139f1c562fc24135880ed4
CVE: CVE-2023-54061
Published: 2025-12-24
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-54062
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix invalid free tracking in ext4_xattr_move_to_block()

In ext4_xattr_move_to_block(), the value of the extended attribute
which we need to move to an external block may be allocated by
kvmalloc() if the value is stored in an external inode.  So at the end
of the function the code tried to check if this was the case by
testing entry->e_value_inum.

However, at this point, the pointer to the xattr entry is no longer
valid, because it was removed from the original location where it had
been stored.  So we could end up calling kvfree() on a pointer which
was not allocated by kvmalloc(); or we could also potentially leak
memory by not freeing the buffer when it should be freed.  Fix this by
storing whether it should be freed in a separate variable.
References: https://git.kernel.org/stable/c/1a8822343e67432b658145d2760a524c884da9d4; https://git.kernel.org/stable/c/76887be2a96193cd11be818551b8934ecdb3123f; https://git.kernel.org/stable/c/8beaa3cb293a8f7bacf711cf52201d59859dbc40
CVE: CVE-2023-54063
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix OOB read in indx_insert_into_buffer

Syzbot reported a OOB read bug:

BUG: KASAN: slab-out-of-bounds in indx_insert_into_buffer+0xaa3/0x13b0
fs/ntfs3/index.c:1755
Read of size 17168 at addr ffff8880255e06c0 by task syz-executor308/3630

Call Trace:
 <TASK>
 memmove+0x25/0x60 mm/kasan/shadow.c:54
 indx_insert_into_buffer+0xaa3/0x13b0 fs/ntfs3/index.c:1755
 indx_insert_entry+0x446/0x6b0 fs/ntfs3/index.c:1863
 ntfs_create_inode+0x1d3f/0x35c0 fs/ntfs3/inode.c:1548
 ntfs_create+0x3e/0x60 fs/ntfs3/namei.c:100
 lookup_open fs/namei.c:3413 [inline]

If the member struct INDEX_BUFFER *index of struct indx_node is
incorrect, that is, the value of __le32 used is greater than the value
of __le32 total in struct INDEX_HDR. Therefore, OOB read occurs when
memmove is called in indx_insert_into_buffer().
Fix this by adding a check in hdr_find_e().
References: https://git.kernel.org/stable/c/17048287ac79abd33b275ac3b5738285d406481b; https://git.kernel.org/stable/c/4bf3b564e27a518f158a83d5e1a50064ed6136a0; https://git.kernel.org/stable/c/a7e5dba10ba1402dd6c2f961a[PII_REDACTED]5c4a5
CVE: CVE-2023-54064
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ipmi:ssif: Fix a memory leak when scanning for an adapter

The adapter scan ssif_info_find() sets info->adapter_name if the adapter
info came from SMBIOS, as it's not set in that case.  However, this
function can be called more than once, and it will leak the adapter name
if it had already been set.  So check for NULL before setting it.
References: https://git.kernel.org/stable/c/13623b966bb6d36ba61646b69cd49cdac6e4978a; https://git.kernel.org/stable/c/3ad53071fe8547eb8d[PII_REDACTED]cc43246008ee; https://git.kernel.org/stable/c/74a1194cce60a90723d0fe148863c18931a31153
CVE: CVE-2023-54065
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: realtek: fix out-of-bounds access

The probe function sets priv->chip_data to (void *)priv + sizeof(*priv)
with the expectation that priv has enough trailing space.

However, only realtek-smi actually allocated this chip_data space.
Do likewise in realtek-mdio to fix out-of-bounds accesses.

These accesses likely went unnoticed so far, because of an (unused)
buf[4096] member in struct realtek_priv, which caused kmalloc to
round up the allocated buffer to a big enough size, so nothing of
value was overwritten. With a different allocator (like in the barebox
bootloader port of the driver) or with KASAN, the memory corruption
becomes quickly apparent.
References: https://git.kernel.org/stable/c/b93eb564869321d0dffaf23fcc5c88112ed62466; https://git.kernel.org/stable/c/cc0f9bb99735d2b68fac68f37b585d615728ce5b; https://git.kernel.org/stable/c/fe668aa499b4b95425044ba11af9609db6ecf466
CVE: CVE-2023-54066
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xfer

In gl861_i2c_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach gl861_i2c_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.

Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
References: https://git.kernel.org/stable/c/2a33fc57133d6f39d62285df6706aeb1714967f1; https://git.kernel.org/stable/c/578b67614ae0e4fba3945b66a4c8f9ae77115bcb; https://git.kernel.org/stable/c/72af676551efe820e309a6c7681c2c4372f37376
CVE: CVE-2023-54068
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()

BUG_ON() will be triggered when writing files concurrently,
because the same page is writtenback multiple times.

1597 void folio_end_writeback(struct folio *folio)
1598 {
		......
1618     if (!__folio_end_writeback(folio))
1619         BUG();
		......
1625 }

kernel BUG at mm/filemap.c:1619!
Call Trace:
 <TASK>
 f2fs_write_end_io+0x1a0/0x370
 blk_update_request+0x6c/0x410
 blk_mq_end_request+0x15/0x130
 blk_complete_reqs+0x3c/0x50
 __do_softirq+0xb8/0x29b
 ? sort_range+0x20/0x20
 run_ksoftirqd+0x19/0x20
 smpboot_thread_fn+0x10b/0x1d0
 kthread+0xde/0x110
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 </TASK>

Below is the concurrency scenario:

[Process A]		[Process B]		[Process C]
f2fs_write_raw_pages()
  - redirty_page_for_writepage()
  - unlock page()
			f2fs_do_write_data_page()
			  - lock_page()
			  - clear_page_dirty_for_io()
			  - set_page_writeback() [1st writeback]
			    .....
			    - unlock page()

						generic_perform_write()
						  - f2fs_write_begin()
						    - wait_for_stable_page()

						  - f2fs_write_end()
						    - set_page_dirty()

  - lock_page()
    - f2fs_do_write_data_page()
      - set_page_writeback() [2st writeback]

This problem was introduced by the previous commit 7377e853967b ("f2fs:
compress: fix potential deadlock of compress file"). All pagelocks were
released in f2fs_write_raw_pages(), but whether the page was
in the writeback state was ignored in the subsequent writing process.
Let's fix it by waiting for the page to writeback before writing.
References: https://git.kernel.org/stable/c/169134da419cb8ffbe3b0743bc24573e16952ea9; https://git.kernel.org/stable/c/6604df2a9d07ba8f8fb1ac14046c2c83776faa4f; https://git.kernel.org/stable/c/9940877c4fe752923a53f0f7372f2f152b6eccf0
CVE: CVE-2023-54069
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow

When we calculate the end position of ext4_free_extent, this position may
be exactly where ext4_lblk_t (i.e. uint) overflows. For example, if
ac_g_ex.fe_logical is[PII_REDACTED] and ac_orig_goal_len is 2048, then the
computed end is 0x100000000, which is 0. If ac->ac_o_ex.fe_logical is not
the first case of adjusting the best extent, that is, new_bex_end > 0, the
following BUG_ON will be triggered:

=========================================================
kernel BUG at fs/ext4/mballoc.c:5116!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279
RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430
Call Trace:
 <TASK>
 ext4_mb_use_best_found+0x203/0x2f0
 ext4_mb_try_best_found+0x163/0x240
 ext4_mb_regular_allocator+0x158/0x1550
 ext4_mb_new_blocks+0x86a/0xe10
 ext4_ext_map_blocks+0xb0c/0x13a0
 ext4_map_blocks+0x2cd/0x8f0
 ext4_iomap_begin+0x27b/0x400
 iomap_iter+0x222/0x3d0
 __iomap_dio_rw+0x243/0xcb0
 iomap_dio_rw+0x16/0x80
=========================================================

A simple reproducer demonstrating the problem:

	mkfs.ext4 -F /dev/sda -b 4096 100M
	mount /dev/sda /tmp/test
	fallocate -l1M /tmp/test/tmp
	fallocate -l10M /tmp/test/file
	fallocate -i -o 1M -l16777203M /tmp/test/file
	fsstress -d /tmp/test -l 0 -n 100000 -p 8 &
	sleep 10 && killall -9 fsstress
	rm -f /tmp/test/tmp
	xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192"

We simply refactor the logic for adjusting the best extent by adding
a temporary ext4_free_extent ex and use extent_logical_end() to avoid
overflow, which also simplifies the code.
References: https://git.kernel.org/stable/c/58fe961c606c446f5612f6897827b1cac42c2e89; https://git.kernel.org/stable/c/83ecffd40c65844a73c2e93d7c[PII_REDACTED]05ac; https://git.kernel.org/stable/c/b7e9ec38b6a0beb5a49cd1e76be0a9a07c218e90
CVE: CVE-2023-54071
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: use work to update rate to avoid RCU warning

The ieee80211_ops::sta_rc_update must be atomic, because
ieee80211_chan_bw_change() holds rcu_read lock while calling
drv_sta_rc_update(), so create a work to do original things.

 Voluntary context switch within RCU read-side critical section!
 WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318
 rcu_note_context_switch+0x571/0x5d0
 CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G        W  OE
 Workqueue: phy3 ieee80211_chswitch_work [mac80211]
 RIP: 0010:rcu_note_context_switch+0x571/0x5d0
 Call Trace:
  <TASK>
  __schedule+0xb0/0x1460
  ? __mod_timer+0x116/0x360
  schedule+0x5a/0xc0
  schedule_timeout+0x87/0x150
  ? trace_raw_output_tick_stop+0x60/0x60
  wait_for_completion_timeout+0x7b/0x140
  usb_start_wait_urb+0x82/0x160 [usbcore
  usb_control_msg+0xe3/0x140 [usbcore
  rtw_usb_read+0x88/0xe0 [rtw_usb
  rtw_usb_read8+0xf/0x10 [rtw_usb
  rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core
  rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core
  drv_sta_rc_update+0x7c/0x160 [mac80211
  ieee80211_chan_bw_change+0xfb/0x110 [mac80211
  ieee80211_change_chanctx+0x38/0x130 [mac80211
  ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211
  ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211
  ieee80211_chswitch_work+0x95/0x170 [mac80211
  process_one_work+0x201/0x410
  worker_thread+0x4a/0x3b0
  ? process_one_work+0x410/0x410
  kthread+0xe1/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x1f/0x30
  </TASK>
References: https://git.kernel.org/stable/c/107677a8f43521e33e4a653e50fdf55ba622a4ce; https://git.kernel.org/stable/c/bcafcb959a57a6890e900199690c5fc47da1a304; https://git.kernel.org/stable/c/dd3af22323e79a2ffabed366db20aab83716fe6f
CVE: CVE-2023-54072
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Fix potential data race at PCM memory allocation helpers

The PCM memory allocation helpers have a sanity check against too many
buffer allocations.  However, the check is performed without a proper
lock and the allocation isn't serialized; this allows user to allocate
more memories than predefined max size.

Practically seen, this isn't really a big problem, as it's more or
less some "soft limit" as a sanity check, and it's not possible to
allocate unlimitedly.  But it's still better to address this for more
consistent behavior.

The patch covers the size check in do_alloc_pages() with the
card->memory_mutex, and increases the allocated size there for
preventing the further overflow.  When the actual allocation fails,
the size is decreased accordingly.
References: https://git.kernel.org/stable/c/3eb4e47a94e3f76521d7d344696db61e6a9619c7; https://git.kernel.org/stable/c/773ccad902f67583a58b5650a2f8d8daf2e76fac; https://git.kernel.org/stable/c/7e11c58b2620a22c67a5ae28d64ce383890ee9f4
CVE: CVE-2023-54073
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: Add !tpm_amd_is_rng_defective() to the hwrng_unregister() call site

The following crash was reported:

[ 1950.279393] list_del corruption, ffff99560d485790->next is NULL
[ 1950.279400] ------------[ cut here ]------------
[ 1950.279401] kernel BUG at lib/list_debug.c:49!
[ 1950.279405] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 1950.279407] CPU: 11 PID: 5886 Comm: modprobe Tainted: G O 6.2.8_1 #1
[ 1950.279409] Hardware name: Gigabyte Technology Co., Ltd. B550M AORUS PRO-P/B550M AORUS PRO-P,
BIOS F15c 05/11/2022
[ 1950.279410] RIP: 0010:__list_del_entry_valid+0x59/0xc0
[ 1950.279415] Code: 48 8b 01 48 39 f8 75 5a 48 8b 72 08 48 39 c6 75 65 b8 01 00 00 00 c3 cc cc cc
cc 48 89 fe 48 c7 c7 08 a8 13 9e e8 b7 0a bc ff <0f> 0b 48 89 fe 48 c7 c7 38 a8 13 9e e8 a6 0a bc
ff 0f 0b 48 89 fe
[ 1950.279416] RSP: 0018:ffffa96d05647e08 EFLAGS: 00010246
[ 1950.279418] RAX: [PII_REDACTED] RBX: ffff99560d485750 RCX: [PII_REDACTED]
[ 1950.279419] RDX: [PII_REDACTED] RSI: ffffffff9e107c59 RDI: 00000000ffffffff
[ 1950.279420] RBP: ffffffffc19c5168 R08: [PII_REDACTED] R09: ffffa96d05647cc8
[ 1950.279421] R10: [PII_REDACTED] R11: ffffffff9ea2a568 R12: [PII_REDACTED]
[ 1950.279422] R13: ffff99560140a2e0 R14: ffff99560127d2e0 R15: [PII_REDACTED]
[ 1950.279422] FS: 00007f67da795380(0000) GS:ffff995d1f0c0000(0000) knlGS:[PII_REDACTED]
[ 1950.279424] CS: 0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ 1950.279424] CR2: 00007f67da7e65c0 CR3: 00000001feed2000 CR4:[PII_REDACTED]750ee0
[ 1950.279426] PKRU: 55555554
[ 1950.279426] Call Trace:
[ 1950.279428] <TASK>
[ 1950.279430] hwrng_unregister+0x28/0xe0 [rng_core]
[ 1950.279436] tpm_chip_unregister+0xd5/0xf0 [tpm]

Add the forgotten !tpm_amd_is_rng_defective() invariant to the
hwrng_unregister() call site inside tpm_chip_unregister().
References: https://git.kernel.org/stable/c/0af0a989e747248e[PII_REDACTED]1225e5b94cdb9e; https://git.kernel.org/stable/c/1408d27f25c7b73ece7545cb6434965eedc49ddb; https://git.kernel.org/stable/c/8da5ba044ea74105f3cfa182603b2f2d766fb22d
CVE: CVE-2023-54074
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Use correct encap attribute during invalidation

With introduction of post action infrastructure most of the users of encap
attribute had been modified in order to obtain the correct attribute by
calling mlx5e_tc_get_encap_attr() helper instead of assuming encap action
is always on default attribute. However, the cited commit didn't modify
mlx5e_invalidate_encap() which prevents it from destroying correct modify
header action which leads to a warning [0]. Fix the issue by using correct
attribute.

[0]:

Feb 21 09:47:35 c-237-177-40-045 kernel: WARNING: CPU: 17 PID: 654 at drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:684 mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core]
Feb 21 09:47:35 c-237-177-40-045 kernel: RIP: 0010:mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core]
Feb 21 09:47:35 c-237-177-40-045 kernel: Call Trace:
Feb 21 09:47:35 c-237-177-40-045 kernel:  <TASK>
Feb 21 09:47:35 c-237-177-40-045 kernel:  mlx5e_tc_fib_event_work+0x8e3/0x1f60 [mlx5_core]
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? mlx5e_take_all_encap_flows+0xe0/0xe0 [mlx5_core]
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? lock_downgrade+0x6d0/0x6d0
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? lockdep_hardirqs_on_prepare+0x273/0x3f0
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? lockdep_hardirqs_on_prepare+0x273/0x3f0
Feb 21 09:47:35 c-237-177-40-045 kernel:  process_one_work+0x7c2/0x1310
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? lockdep_hardirqs_on_prepare+0x3f0/0x3f0
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? pwq_dec_nr_in_flight+0x230/0x230
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? rwlock_bug.part.0+0x90/0x90
Feb 21 09:47:35 c-237-177-40-045 kernel:  worker_thread+0x59d/0xec0
Feb 21 09:47:35 c-237-177-40-045 kernel:  ? __kthread_parkme+0xd9/0x1d0
References: https://git.kernel.org/stable/c/00959a1bad58e4b6c14a2729f84d[PII_REDACTED]09; https://git.kernel.org/stable/c/b8b4292fdd8818ab43b943b[PII_REDACTED]f51e39f; https://git.kernel.org/stable/c/be071cdb167fc3e25fe81922166b3d499d23e8ac
CVE: CVE-2023-54075
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: mediatek: common: Fix refcount leak in parse_dai_link_info

Add missing of_node_put()s before the returns to balance
of_node_get()s and of_node_put()s, which may get unbalanced
in case the for loop 'for_each_available_child_of_node' returns
early.
References: https://git.kernel.org/stable/c/3e40722d55805584dc04d8594d912820cafb2432; https://git.kernel.org/stable/c/beed115c2ce78f990222a29abed042582df4e87c
CVE: CVE-2023-54076
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix missed ses refcounting

Use new cifs_smb_ses_inc_refcount() helper to get an active reference
of @ses and @ses->dfs_root_ses (if set).  This will prevent
@ses->dfs_root_ses of being put in the next call to cifs_put_smb_ses()
and thus potentially causing an use-after-free bug.
References: https://git.kernel.org/stable/c/bf99f6be2d20146942bce6f9e90a0ceef12cbc1e; https://git.kernel.org/stable/c/eb382196e6f6e05cfafdab797840e5a96c6e7bf0
CVE: CVE-2023-54077
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix memory leak if ntfs_read_mft failed

Label ATTR_ROOT in ntfs_read_mft() sets is_root = true and
ni->ni_flags |= NI_FLAG_DIR, then next attr will goto label ATTR_ALLOC
and alloc ni->dir.alloc_run. However two states are not always
consistent and can make memory leak.

 1) attr_name in ATTR_ROOT does not fit the condition it will set
 is_root = true but NI_FLAG_DIR is not set.
 2) next attr_name in ATTR_ALLOC fits the condition and alloc
 ni->dir.alloc_run
 3) in cleanup function ni_clear(), when NI_FLAG_DIR is set, it frees
 ni->dir.alloc_run, otherwise it frees ni->file.run
 4) because NI_FLAG_DIR is not set in this case, ni->dir.alloc_run is
 leaked as kmemleak reported:

unreferenced object 0xffff888003bc5480 (size 64):
  backtrace:
    [<000000003d42e6b0>] __kmalloc_node+0x4e/0x1c0
    [<00000000d8e19b8a>] kvmalloc_node+0x39/0x1f0
    [<00000000fc3eb5b8>] run_add_entry+0x18a/0xa40 [ntfs3]
    [<[PII_REDACTED]c9f978>] run_unpack+0x75d/0x8e0 [ntfs3]
    [<00000000e7cf1819>] run_unpack_ex+0xbc/0x500 [ntfs3]
    [<00000000bbf0a43d>] ntfs_iget5+0xb25/0x2dd0 [ntfs3]
    [<00000000a6e50693>] ntfs_fill_super+0x218d/0x3580 [ntfs3]
    [<00000000b9170608>] get_tree_bdev+0x3fb/0x710
    [<[PII_REDACTED]33798a>] vfs_get_tree+0x8e/0x280
    [<000000006e20b8e6>] path_mount+0xf3c/0x1930
    [<000000007bf15a5f>] do_mount+0xf3/0x110
    ...

Fix this by always setting is_root and NI_FLAG_DIR together.
References: https://git.kernel.org/stable/c/1bc6bb657dfb0ab3b94ef6d477ca241bf7b6ec06; https://git.kernel.org/stable/c/3030f2b9b3329db3948c1a145a5493ca6f617d50; https://git.kernel.org/stable/c/3bb0d3eb475f01744ce6d6e998dfbd80220852a1
CVE: CVE-2023-54078
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: max9286: Free control handler

The control handler is leaked in some probe-time error paths, as well as
in the remove path. Fix it.
References: https://git.kernel.org/stable/c/0f25f99dacc72bce7d4128f7a254b23f1a343cc7; https://git.kernel.org/stable/c/19f36204dbe28bf4ec0149e87e9996a56af4e654; https://git.kernel.org/stable/c/1ad4b8c4552b4096dfc86531462dc1899f96af94