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

MIPS: fw: Allow firmware to pass a empty env

fw_getenv will use env entry to determine style of env,
however it is legal for firmware to just pass a empty list.

Check if first entry exist before running strchr to avoid
null pointer dereference.
References: https://git.kernel.org/stable/c/0f91290774c798199ba4b8df93de5c3156b5163d; https://git.kernel.org/stable/c/3ef93b7bd9e042db240843f24a80e14da38c6830; https://git.kernel.org/stable/c/47e61cadc7a5f3dffd42d2d6fda81be163f1ab82
CVE: CVE-2023-54280
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix potential race when tree connecting ipc

Protect access of TCP_Server_Info::hostname when building the ipc tree
name as it might get freed in cifsd thread and thus causing an
use-after-free bug in __tree_connect_dfs_target().  Also, while at it,
update status of IPC tcon on success and then avoid any extra tree
connects.
References: https://git.kernel.org/stable/c/536ec71ba060a02fabe8e22cecb82fe7b3a8708b; https://git.kernel.org/stable/c/553476df55a111e6a66ad9155256aec0ec1b7ad0; https://git.kernel.org/stable/c/ee20d7c6100752eaf2409d783f4f1449c29ea33d
CVE: CVE-2023-54282
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

media: tuners: qt1010: replace BUG_ON with a regular error

BUG_ON is unnecessary here, and in addition it confuses smatch.
Replacing this with an error return help resolve this smatch
warning:

drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow 'i2c_data' 34 <= 34
References: https://git.kernel.org/stable/c/1a6bf53fffe0b7ebe2a0f402b44f14f90cffd164; https://git.kernel.org/stable/c/257092cb544c7843376b3e161f789e666ef06c98; https://git.kernel.org/stable/c/2ae53dd15eef90d34fc084b5b2305a67bb675a26
CVE: CVE-2023-54283
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Address KCSAN report on bpf_lru_list

KCSAN reported a data-race when accessing node->ref.
Although node->ref does not have to be accurate,
take this chance to use a more common READ_ONCE() and WRITE_ONCE()
pattern instead of data_race().

There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().
This patch also adds bpf_lru_node_clear_ref() to do the
WRITE_ONCE(node->ref, 0) also.

==================================================================
BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elem

write to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:
__bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]
__bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]
__bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240
bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]
bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]
bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499
prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]
__htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316
bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313
bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200
generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687
bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534
__sys_bpf+0x338/0x810
__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]
__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

read to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:
bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]
__htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332
bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313
bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200
generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687
bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534
__sys_bpf+0x338/0x810
__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]
__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

value changed: 0x01 -> 0x00

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
==================================================================
References: https://git.kernel.org/stable/c/6e5e83b56f50fbd1c8f7dca7df7d72c67be25571; https://git.kernel.org/stable/c/6eaef1b1d8720053eb1b6e7a3ff8b2ff0716bb90; https://git.kernel.org/stable/c/819ca25444b377935faa2dbb0aa3547519b5c80f
CVE: CVE-2023-54284
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

media: av7110: prevent underflow in write_ts_to_decoder()

The buf[4] value comes from the user via ts_play().  It is a value in
the u8 range.  The final length we pass to av7110_ipack_instant_repack()
is "len - (buf[4] + 1) - 4" so add a check to ensure that the length is
not negative.  It's not clear that passing a negative len value does
anything bad necessarily, but it's not best practice.

With the new bounds checking the "if (!len)" condition is no longer
possible or required so remove that.
References: https://git.kernel.org/stable/c/423350af9e27f005611bd881b1df2cab66de943d; https://git.kernel.org/stable/c/620b983589e0223876bf1463b01100a9c67b56ba; https://git.kernel.org/stable/c/6606e2404ee9e20a3ae5b42fc3660d41b739ed3e
CVE: CVE-2023-54285
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

iomap: Fix possible overflow condition in iomap_write_delalloc_scan

folio_next_index() returns an unsigned long value which left shifted
by PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead
use folio_pos(folio) + folio_size(folio), which does this correctly.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0c6cf409093f307ee05114f834516730c0da5b21; https://git.kernel.org/stable/c/5c281b0c5d18c8eeb1cfd5023f4adb153e6d1240; https://git.kernel.org/stable/c/eee2d2e6ea[PII_REDACTED]dbd5bb1316ceb38455fb
CVE: CVE-2023-54286
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtrace

A received TKIP key may be up to 32 bytes because it may contain
MIC rx/tx keys too. These are not used by iwl and copying these
over overflows the iwl_keyinfo.key field.

Add a check to not copy more data to iwl_keyinfo.key then will fit.

This fixes backtraces like this one:

 memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16)
 WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm]
 <snip>
 Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017
 RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm]
 <snip>
 Call Trace:
  <TASK>
  iwl_set_dynamic_key+0x1f0/0x220 [iwldvm]
  iwlagn_mac_set_key+0x1e4/0x280 [iwldvm]
  drv_set_key+0xa4/0x1b0 [mac80211]
  ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211]
  ieee80211_key_replace+0x22d/0x8e0 [mac80211]
 <snip>
References: https://git.kernel.org/stable/c/3ed3c1c2fc3482b72e[PII_REDACTED]79cd2e2c5a3e; https://git.kernel.org/stable/c/57189c885149825be8eb8c3524b5af017fdeb941; https://git.kernel.org/stable/c/6cd644f66b[PII_REDACTED]1d63e0173cb0c7aab159
CVE: CVE-2023-54287
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: serial: imx: disable Ageing Timer interrupt request irq

There maybe pending USR interrupt before requesting irq, however
uart_add_one_port has not executed, so there will be kernel panic:
[    0.795668] Unable to handle kernel NULL pointer dereference at virtual addre
ss [PII_REDACTED]
[    0.802701] Mem abort info:
[    0.805367]   ESR = 0x[PII_REDACTED]000004
[    0.808950]   EC = 0x25: DABT (current EL), IL = 32 bits
[    0.814033]   SET = 0, FnV = 0
[    0.816950]   EA = 0, S1PTW = 0
[    0.819950]   FSC = 0x04: level 0 translation fault
[    0.824617] Data abort info:
[    0.827367]   ISV = 0, ISS = 0x00000004
[    0.831033]   CM = 0, WnR = 0
[    0.833866] [[PII_REDACTED]] user address but active_mm is swapper
[    0.839951] Internal error: Oops: [PII_REDACTED] [#1] PREEMPT SMP
[    0.845953] Modules linked in:
[    0.848869] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.1+g56321e101aca #1
[    0.855617] Hardware name: Freescale i.MX8MP EVK (DT)
[    0.860452] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    0.867117] pc : __imx_uart_rxint.constprop.0+0x11c/0x2c0
[    0.872283] lr : imx_uart_int+0xf8/0x1ec

The issue only happends in the inmate linux when Jailhouse hypervisor
enabled. The test procedure is:
while true; do
	jailhouse enable imx8mp.cell
	jailhouse cell linux xxxx
	sleep 10
	jailhouse cell destroy 1
	jailhouse disable
	sleep 5
done

And during the upper test, press keys to the 2nd linux console.
When `jailhouse cell destroy 1`, the 2nd linux has no chance to put
the uart to a quiese state, so USR1/2 may has pending interrupts. Then
when `jailhosue cell linux xx` to start 2nd linux again, the issue
trigger.

In order to disable irqs before requesting them, both UCR1 and UCR2 irqs
should be disabled, so here fix that, disable the Ageing Timer interrupt
in UCR2 as UCR1 does.
References: https://git.kernel.org/stable/c/3d41d9b256ae626c0dc434427c8e32450358d3b4; https://git.kernel.org/stable/c/963875b[PII_REDACTED]775b0ea614aab8b6b3eb001; https://git.kernel.org/stable/c/9795ece3a85ba9238191e97665586e2d79703ff3
CVE: CVE-2023-54289
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: qedf: Fix NULL dereference in error handling

Smatch reported:

drivers/scsi/qedf/qedf_main.c:3056 qedf_alloc_global_queues()
warn: missing unwind goto?

At this point in the function, nothing has been allocated so we can return
directly. In particular the "qedf->global_queues" have not been allocated
so calling qedf_free_global_queues() will lead to a NULL dereference when
we check if (!gl[i]) and "gl" is NULL.
References: https://git.kernel.org/stable/c/08c001c1e9444a3046c79a99aa93ac48073b18cc; https://git.kernel.org/stable/c/271c9b2eb60149afbeab28cb39e52f73bde9900c; https://git.kernel.org/stable/c/961c8370c5f7e80a267680476e1bcff34bffe71a
CVE: CVE-2023-54290
Published: 2025-12-30
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-54292
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/irdma: Fix data race on CQP request done

KCSAN detects a data race on cqp_request->request_done memory location
which is accessed locklessly in irdma_handle_cqp_op while being
updated in irdma_cqp_ce_handler.

Annotate lockless intent with READ_ONCE/WRITE_ONCE to avoid any
compiler optimizations like load fusing and/or KCSAN warning.

[[PII_REDACTED]28] BUG: KCSAN: data-race in irdma_cqp_ce_handler [irdma] / irdma_wait_event [irdma]

[[PII_REDACTED]32] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5:
[[PII_REDACTED]10]  irdma_cqp_ce_handler+0x21e/0x270 [irdma]
[[PII_REDACTED]25]  cqp_compl_worker+0x1b/0x20 [irdma]
[[PII_REDACTED]27]  process_one_work+0x4d1/0xa40
[[PII_REDACTED]35]  worker_thread+0x319/0x700
[[PII_REDACTED]42]  kthread+0x180/0x1b0
[[PII_REDACTED]52]  ret_from_fork+0x22/0x30

[[PII_REDACTED]18] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1:
[[PII_REDACTED]95]  irdma_wait_event+0x1e2/0x2c0 [irdma]
[[PII_REDACTED]99]  irdma_handle_cqp_op+0xae/0x170 [irdma]
[[PII_REDACTED]02]  irdma_cqp_cq_destroy_cmd+0x70/0x90 [irdma]
[[PII_REDACTED]08]  irdma_puda_dele_rsrc+0x46d/0x4d0 [irdma]
[[PII_REDACTED]11]  irdma_rt_deinit_hw+0x179/0x1d0 [irdma]
[[PII_REDACTED]14]  irdma_ib_dealloc_device+0x11/0x40 [irdma]
[[PII_REDACTED]18]  ib_dealloc_device+0x2a/0x120 [ib_core]
[[PII_REDACTED]23]  __ib_unregister_device+0xde/0x100 [ib_core]
[[PII_REDACTED]81]  ib_unregister_device+0x22/0x40 [ib_core]
[[PII_REDACTED]42]  irdma_ib_unregister_device+0x70/0x90 [irdma]
[[PII_REDACTED]48]  i40iw_close+0x6f/0xc0 [irdma]
[[PII_REDACTED]52]  i40e_client_device_unregister+0x14a/0x180 [i40e]
[[PII_REDACTED]50]  i40iw_remove+0x21/0x30 [irdma]
[[PII_REDACTED]54]  auxiliary_bus_remove+0x31/0x50
[[PII_REDACTED]63]  device_remove+0x69/0xb0
[[PII_REDACTED]72]  device_release_driver_internal+0x293/0x360
[[PII_REDACTED]82]  driver_detach+0x7c/0xf0
[[PII_REDACTED]92]  bus_remove_driver+0x8c/0x150
[[PII_REDACTED]00]  driver_unregister+0x45/0x70
[[PII_REDACTED]10]  auxiliary_driver_unregister+0x16/0x30
[[PII_REDACTED]18]  irdma_exit_module+0x18/0x1e [irdma]
[[PII_REDACTED]33]  __do_sys_delete_module.constprop.0+0x1e2/0x310
[[PII_REDACTED]45]  __x64_sys_delete_module+0x1b/0x30
[[PII_REDACTED]55]  do_syscall_64+0x39/0x90
[[PII_REDACTED]63]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

[[PII_REDACTED]29] value changed: 0x01 -> 0x03
References: https://git.kernel.org/stable/c/5986e96be7d0b82e50a9c6b019ea3f1926fd8764; https://git.kernel.org/stable/c/b8b90ba636e3861665aef9a3eab5fcf92839a2c5; https://git.kernel.org/stable/c/c5b5dbcbf91f769b8eb25f88e32a1522f920f37a
CVE: CVE-2023-54293
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

bcache: fixup btree_cache_wait list damage

We get a kernel crash about "list_add corruption. next->prev should be
prev (ffff9c801bc01210), but was ffff9c77b688237c.
(next=ffffae586d8afe68)."

crash> struct list_head 0xffff9c801bc01210
struct list_head {
  next = 0xffffae586d8afe68,
  prev = 0xffffae586d8afe68
}
crash> struct list_head 0xffff9c77b688237c
struct list_head {
  next = 0x0,
  prev = 0x0
}
crash> struct list_head 0xffffae586d8afe68
struct list_head struct: invalid kernel virtual address: ffffae586d8afe68  type: "gdb_readmem_callback"
Cannot access memory at address 0xffffae586d8afe68

[[PII_REDACTED]92] Call Trace:
[[PII_REDACTED]41]  prepare_to_wait+0x8a/0xb0
[[PII_REDACTED]63]  ? bch_btree_keys_free+0x6c/0xc0 [escache]
[[PII_REDACTED]33]  mca_cannibalize_lock+0x72/0x90 [escache]
[[PII_REDACTED]88]  mca_alloc+0x2ae/0x450 [escache]
[[PII_REDACTED]90]  bch_btree_node_get+0x136/0x2d0 [escache]
[[PII_REDACTED]81]  bch_btree_check_thread+0x1e1/0x260 [escache]
[[PII_REDACTED]82]  ? finish_wait+0x80/0x80
[[PII_REDACTED]84]  ? bch_btree_check_recurse+0x1a0/0x1a0 [escache]
[[PII_REDACTED]59]  kthread+0x112/0x130
[[PII_REDACTED]48]  ? kthread_flush_work_fn+0x10/0x10
[[PII_REDACTED]77]  ret_from_fork+0x35/0x40

bch_btree_check_thread() and bch_dirty_init_thread() may call
mca_cannibalize() to cannibalize other cached btree nodes. Only one thread
can do it at a time, so the op of other threads will be added to the
btree_cache_wait list.

We must call finish_wait() to remove op from btree_cache_wait before free
it's memory address. Otherwise, the list will be damaged. Also should call
bch_cannibalize_unlock() to release the btree_cache_alloc_lock and wake_up
other waiters.
References: https://git.kernel.org/stable/c/25ec4779d0fb3ed9cac1e4d9e0e4261b4a12f6ed; https://git.kernel.org/stable/c/2882a4c4f0c90e99f37dbd8db369b9982fd613e7; https://git.kernel.org/stable/c/bcb295778afda4f2feb0d3c0289a53fd43d5a3a6
CVE: CVE-2023-54294
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix memleak of md thread

In raid10_run(), if setup_conf() succeed and raid10_run() failed before
setting 'mddev->thread', then in the error path 'conf->thread' is not
freed.

Fix the problem by setting 'mddev->thread' right after setup_conf().
References: https://git.kernel.org/stable/c/2a65555f7e0f4a05b663879908a991e6d9f81e51; https://git.kernel.org/stable/c/36ba0c7b86acd9c2ea80a273204d52c21c955471; https://git.kernel.org/stable/c/3725b35fc0e5e4eea0434ef625f3d92f3059d080
CVE: CVE-2023-54295
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type

spi_nor_set_erase_type() was used either to set or to mask out an erase
type. When we used it to mask out an erase type a shift-out-of-bounds
was hit:
UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
shift exponent[PII_REDACTED] is too large for 32-bit type 'int'

The setting of the size_{shift, mask} and of the opcode are unnecessary
when the erase size is zero, as throughout the code just the erase size
is considered to determine whether an erase type is supported or not.
Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF
is an unused opcode. Thus when masking out an erase type, just set the
erase size to zero. This will fix the shift-out-of-bounds.

[ta: refine changes, new commit message, fix compilation error]
References: https://git.kernel.org/stable/c/53b2916ebde741c657a857fa1936c0d9fcb59170; https://git.kernel.org/stable/c/61d44a4db2f54dbac7d22c2541574ea5755e0468; https://git.kernel.org/stable/c/99341b8aee7b5b4255b339345bbcaa35867dfd0c
CVE: CVE-2023-54296
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migration

Fix a goof where KVM tries to grab source vCPUs from the destination VM
when doing intrahost migration.  Grabbing the wrong vCPU not only hoses
the guest, it also crashes the host due to the VMSA pointer being left
NULL.

  BUG: unable to handle page fault for address: ffffe[PII_REDACTED]0
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP NOPTI
  CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO       6.5.0-smp--fff2e47e6c3b-next #151
  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023
  RIP: 0010:__free_pages+0x15/0xd0
  RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246
  RAX: [PII_REDACTED] RBX: ffffe[PII_REDACTED]0 RCX: [PII_REDACTED]
  RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffffe[PII_REDACTED]0
  RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: [PII_REDACTED]
  R10: [PII_REDACTED] R11: ffffffff83619b90 R12: ffff923fa9540000
  R13: [PII_REDACTED] R14: ffff923f6d35d000 R15: [PII_REDACTED]
  FS:  [PII_REDACTED](0000) GS:ffff929d0d7c0000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: ffffe[PII_REDACTED]0 CR3:[PII_REDACTED]c34005 CR4:[PII_REDACTED]770ee0
  PKRU: 55555554
  Call Trace:
   <TASK>
   sev_free_vcpu+0xcb/0x110 [kvm_amd]
   svm_vcpu_free+0x75/0xf0 [kvm_amd]
   kvm_arch_vcpu_destroy+0x36/0x140 [kvm]
   kvm_destroy_vcpus+0x67/0x100 [kvm]
   kvm_arch_destroy_vm+0x161/0x1d0 [kvm]
   kvm_put_kvm+0x276/0x560 [kvm]
   kvm_vm_release+0x25/0x30 [kvm]
   __fput+0x106/0x280
   ____fput+0x12/0x20
   task_work_run+0x86/0xb0
   do_exit+0x2e3/0x9c0
   do_group_exit+0xb1/0xc0
   __x64_sys_exit_group+0x1b/0x20
   do_syscall_64+0x41/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
   </TASK>
  CR2: ffffe[PII_REDACTED]0
References: https://git.kernel.org/stable/c/2ee4b180d51b12a45bdd[PII_REDACTED]ef6a572a73; https://git.kernel.org/stable/c/5c18ace750e4d4d58d7da02d1c669bf21c824158; https://git.kernel.org/stable/c/f1187ef24eb8f36e8ad8106d22615ceddeea6097
CVE: CVE-2023-54297
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: zoned: fix memory leak after finding block group with super blocks

At exclude_super_stripes(), if we happen to find a block group that has
super blocks mapped to it and we are on a zoned filesystem, we error out
as this is not supposed to happen, indicating either a bug or maybe some
memory corruption for example. However we are exiting the function without
freeing the memory allocated for the logical address of the super blocks.
Fix this by freeing the logical address.
References: https://git.kernel.org/stable/c/ab80a901f8daca07c4a54af0ab0de745c9918294; https://git.kernel.org/stable/c/c35ea[PII_REDACTED]63e63785918c7c8fe27c45798; https://git.kernel.org/stable/c/cca627afb463a4b47721eac017516ba200de85c3
CVE: CVE-2023-54298
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal: intel: quark_dts: fix error pointer dereference

If alloc_soc_dts() fails, then we can just return.  Trying to free
"soc_dts" will lead to an Oops.
References: https://git.kernel.org/stable/c/0b366c6a42e2e2bc67af8d1130b68f3bfa31c80e; https://git.kernel.org/stable/c/24c221b11c2894e1a5f07b93362d9bc91c6d8be7; https://git.kernel.org/stable/c/5eaf55b38691291d49417c22e726591078ca1893
CVE: CVE-2023-54299
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: bus: verify partner exists in typec_altmode_attention

Some usb hubs will negotiate DisplayPort Alt mode with the device
but will then negotiate a data role swap after entering the alt
mode. The data role swap causes the device to unregister all alt
modes, however the usb hub will still send Attention messages
even after failing to reregister the Alt Mode. type_altmode_attention
currently does not verify whether or not a device's altmode partner
exists, which results in a NULL pointer error when dereferencing
the typec_altmode and typec_altmode_ops belonging to the altmode
partner.

Verify the presence of a device's altmode partner before sending
the Attention message to the Alt Mode driver.
References: https://git.kernel.org/stable/c/0ad6bad31da692f8d7acacab07eabe7586239ae0; https://git.kernel.org/stable/c/0d3b5fe47938e9c[PII_REDACTED]04a2bd74e967a80; https://git.kernel.org/stable/c/1101867a1711c27d8bbe0e83136bec47f8c1ca2a
CVE: CVE-2023-54300
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rx

For the reasons also described in commit b383e8abed41 ("wifi: ath9k: avoid
uninit memory read in ath9k_htc_rx_msg()"), ath9k_htc_rx_msg() should
validate pkt_len before accessing the SKB.

For example, the obtained SKB may have been badly constructed with
pkt_len = 8. In this case, the SKB can only contain a valid htc_frame_hdr
but after being processed in ath9k_htc_rx_msg() and passed to
ath9k_wmi_ctrl_rx() endpoint RX handler, it is expected to have a WMI
command header which should be located inside its data payload.

Implement sanity checking inside ath9k_wmi_ctrl_rx(). Otherwise, uninit
memory can be referenced.

Tested on Qualcomm Atheros Communications AR9271 802.11n .

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
References: https://git.kernel.org/stable/c/0bc12e41af4e3ae1f0efecc377f0514459df0707; https://git.kernel.org/stable/c/250efb4d3f5b32a115ea6bf25437ba44a1b3c04f; https://git.kernel.org/stable/c/28259ce4f1f1f9ab37fa817756c89098213d2fc0
CVE: CVE-2023-54301
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: 8250_bcm7271: fix leak in `brcmuart_probe`

Smatch reports:
drivers/tty/serial/8250/8250_bcm7271.c:1120 brcmuart_probe() warn:
'baud_mux_clk' from clk_prepare_enable() not released on lines: 1032.

The issue is fixed by using a managed clock.
References: https://git.kernel.org/stable/c/2a3e5f428fc4315be[PII_REDACTED]eaefac16f43a9; https://git.kernel.org/stable/c/5258395e67fee6929fb8e50c8239f8de51b8cb2d; https://git.kernel.org/stable/c/56a81445b8e4b8906d557518c5dae3ddbb447d1e