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

scsi: mpi3mr: Fix missing mrioc->evtack_cmds initialization

Commit c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic")
introduced an array mrioc->evtack_cmds but initialization of the array
elements was missed. They are just zero cleared. The function
mpi3mr_complete_evt_ack() refers host_tag field of the elements. Due to the
zero value of the host_tag field, the function calls clear_bit() for
mrico->evtack_cmds_bitmap with wrong bit index. This results in memory
access to invalid address and "BUG: KASAN: use-after-free". This BUG was
observed at eHBA-9600 firmware update to version 8.3.1.0. To fix it, add
the missing initialization of mrioc->evtack_cmds.
References: https://git.kernel.org/stable/c/4e0dfdb48a824deac3dfbc67fb856ef2aee13529; https://git.kernel.org/stable/c/67989091e11a974003ddf2ec39bc613df8eadd83; https://git.kernel.org/stable/c/e39ea831ebad4ab15c4748cb62a397a8abcca36e
CVE: CVE-2023-54235
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI/DOE: Fix destroy_work_on_stack() race

The following debug object splat was observed in testing:

  ODEBUG: free active (active state 0) object:[PII_REDACTED]d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510
  WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0
  ...
  Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work
  RIP: 0010:debug_print_object+0x7d/0xb0
  ...
  Call Trace:
   ? debug_print_object+0x7d/0xb0
   ? __pfx_doe_statemachine_work+0x10/0x10
   debug_object_free.part.0+0x11b/0x150
   doe_statemachine_work+0x45e/0x510
   process_one_work+0x1d4/0x3c0

This occurs because destroy_work_on_stack() was called after signaling
the completion in the calling thread.  This creates a race between
destroy_work_on_stack() and the task->work struct going out of scope in
pci_doe().

Signal the work complete after destroying the work struct.  This is safe
because signal_task_complete() is the final thing the work item does and
the workqueue code is careful not to access the work struct after.
References: https://git.kernel.org/stable/c/19cf3ba16dcc2ef059dcf010072d4f96d76486e0; https://git.kernel.org/stable/c/c4f9c0a3a6df143f2e1092823b7fa9e07d6ab57f; https://git.kernel.org/stable/c/d96799ee3b78962c80e4b6653734f488f999ca09
CVE: CVE-2023-54236
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net/net_failover: fix txq exceeding warning

The failover txq is inited as 16 queues.
when a packet is transmitted from the failover device firstly,
the failover device will select the queue which is returned from
the primary device if the primary device is UP and running.
If the primary device txq is bigger than the default 16,
it can lead to the following warning:
eth0 selects TX queue 18, but real number of TX queues is 16

The warning backtrace is:
[   32.146376] CPU: 18 PID: 9134 Comm: chronyd Tainted: G            E      6.2.8-1.el7.centos.x86_64 #1
[   32.147175] Hardware name: Red Hat KVM, BIOS 1.10.2-3.el7_4.1 04/01/2014
[   32.147730] Call Trace:
[   32.147971]  <TASK>
[   32.148183]  dump_stack_lvl+0x48/0x70
[   32.148514]  dump_stack+0x10/0x20
[   32.148820]  netdev_core_pick_tx+0xb1/0xe0
[   32.149180]  __dev_queue_xmit+0x529/0xcf0
[   32.149533]  ? __check_object_size.part.0+0x21c/0x2c0
[   32.149967]  ip_finish_output2+0x278/0x560
[   32.150327]  __ip_finish_output+0x1fe/0x2f0
[   32.150690]  ip_finish_output+0x2a/0xd0
[   32.151032]  ip_output+0x7a/0x110
[   32.151337]  ? __pfx_ip_finish_output+0x10/0x10
[   32.151733]  ip_local_out+0x5e/0x70
[   32.152054]  ip_send_skb+0x19/0x50
[   32.152366]  udp_send_skb.isra.0+0x163/0x3a0
[   32.152736]  udp_sendmsg+0xba8/0xec0
[   32.153060]  ? __folio_memcg_unlock+0x25/0x60
[   32.153445]  ? __pfx_ip_generic_getfrag+0x10/0x10
[   32.153854]  ? sock_has_perm+0x85/0xa0
[   32.154190]  inet_sendmsg+0x6d/0x80
[   32.154508]  ? inet_sendmsg+0x6d/0x80
[   32.154838]  sock_sendmsg+0x62/0x70
[   32.155152]  ____sys_sendmsg+0x134/0x290
[   32.155499]  ___sys_sendmsg+0x81/0xc0
[   32.155828]  ? _get_random_bytes.part.0+0x79/0x1a0
[   32.156240]  ? ip4_datagram_release_cb+0x5f/0x1e0
[   32.156649]  ? get_random_u16+0x69/0xf0
[   32.156989]  ? __fget_light+0xcf/0x110
[   32.157326]  __sys_sendmmsg+0xc4/0x210
[   32.157657]  ? __sys_connect+0xb7/0xe0
[   32.157995]  ? __audit_syscall_entry+0xce/0x140
[   32.158388]  ? syscall_trace_enter.isra.0+0x12c/0x1a0
[   32.158820]  __x64_sys_sendmmsg+0x24/0x30
[   32.159171]  do_syscall_64+0x38/0x90
[   32.159493]  entry_SYSCALL_64_after_hwframe+0x72/0xdc

Fix that by reducing txq number as the non-existent primary-dev does.
References: https://git.kernel.org/stable/c/105cc268328231d5c2bfcbd03f265cec444a3492; https://git.kernel.org/stable/c/2d5cebf57296f0189a61482035ad420384eedead; https://git.kernel.org/stable/c/44d250c22209c680f61befbc2ac326da5452da01
CVE: CVE-2023-54237
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()

There is a certain chance to trigger the following panic:

PID: 5900   TASK: ffff88c1c8af4100  CPU: 1   COMMAND: "kworker/1:48"
 #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7
 #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a
 #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60
 #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7
 #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715
 #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654
 #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62
    [exception RIP: ib_alloc_mr+19]
    RIP: ffffffffc0c9cce3  RSP: ffff9456c1cc7c38  RFLAGS: 00010202
    RAX: [PII_REDACTED]  RBX: [PII_REDACTED]  RCX: [PII_REDACTED]
    RDX: [PII_REDACTED]  RSI: [PII_REDACTED]  RDI: [PII_REDACTED]
    RBP: ffff88c1ea281d00   R8: 000000020a34ffff   R9: ffff88c1350bbb20
    R10: [PII_REDACTED]  R11: [PII_REDACTED]  R12: [PII_REDACTED]
    R13: [PII_REDACTED]  R14: ffff88c1ab040a50  R15: ffff88c1ea281d00
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]
 #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]
 #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]

The reason here is that when the server tries to create a second link,
smc_llc_srv_add_link() has no protection and may add a new link to
link group. This breaks the security environment protected by
llc_conf_mutex.
References: https://git.kernel.org/stable/c/0c764cc271d3aa6528ae1b3394babf34ac01f775; https://git.kernel.org/stable/c/e40b801b3603a8f90b46acbacdea3505c27f01c0; https://git.kernel.org/stable/c/f2f46de98c11d41ac8d22765f47ba54ce5480a5b
CVE: CVE-2023-54238
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

mlx5: fix skb leak while fifo resync and push

During ptp resync operation SKBs were poped from the fifo but were never
freed neither by napi_consume nor by dev_kfree_skb_any. Add call to
napi_consume_skb to properly free SKBs.

Another leak was happening because mlx5e_skb_fifo_has_room() had an error
in the check. Comparing free running counters works well unless C promotes
the types to something wider than the counter. In this case counters are
u16 but the result of the substraction is promouted to int and it causes
wrong result (negative value) of the check when producer have already
overlapped but consumer haven't yet. Explicit cast to u16 fixes the issue.
References: https://git.kernel.org/stable/c/234cffda95e1049f58e8ec136ef105c633f0ed19; https://git.kernel.org/stable/c/68504c66d08c70fb92799722e25a932d311d74fd; https://git.kernel.org/stable/c/e435941b1da1a0be4ff8a7ae425774c76a5ac514
CVE: CVE-2023-54239
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: Check for uptr overflow

syzkaller found that setting up a map with a user VA that wraps past zero
can trigger WARN_ONs, particularly from pin_user_pages weirdly returning 0
due to invalid arguments.

Prevent creating a pages with a uptr and size that would math overflow.

  WARNING: CPU: 0 PID: 518 at drivers/iommu/iommufd/pages.c:793 pfn_reader_user_pin+0x2e6/0x390
  Modules linked in:
  CPU: 0 PID: 518 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:pfn_reader_user_pin+0x2e6/0x390
  Code: b1 11 e9 25 fe ff ff e8 28 e4 0f ff 31 ff 48 89 de e8 2e e6 0f ff 48 85 db 74 0a e8 14 e4 0f ff e9 4d ff ff ff e8 0a e4 0f ff <0f> 0b bb f2 ff ff ff e9 3c ff ff ff e8 f9 e3 0f ff ba 01 00 00 00
  RSP: 0018:ffffc90000f9fa30 EFLAGS: 00010246
  RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: ffffffff821e2b72
  RDX: [PII_REDACTED] RSI: ffff[PII_REDACTED]80 RDI: [PII_REDACTED]
  RBP: ffffc90000f9fa78 R08:[PII_REDACTED]0000ff R09:[PII_REDACTED]de6f4e
  R10: ffffc90000f9f790 R11: ffff[PII_REDACTED]18 R12: ffffc90000f9fc60
  R13: [PII_REDACTED] R14: ffff[PII_REDACTED]00 R15: [PII_REDACTED]
  FS:  00007f[PII_REDACTED](0000) GS:ffff88807dc00000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: [PII_REDACTED] CR3: 000000000e748005 CR4:[PII_REDACTED]770ef0
  PKRU: 55555554
  Call Trace:
   <TASK>
   pfn_reader_next+0x14a/0x7b0
   ? interval_tree_double_span_iter_update+0x11a/0x140
   pfn_reader_first+0x140/0x1b0
   iopt_pages_rw_slow+0x71/0x280
   ? __this_cpu_preempt_check+0x20/0x30
   iopt_pages_rw_access+0x2b2/0x5b0
   iommufd_access_rw+0x19f/0x2f0
   iommufd_test+0xd11/0x16f0
   ? write_comp_data+0x2f/0x90
   iommufd_fops_ioctl+0x206/0x330
   __x64_sys_ioctl+0x10e/0x160
   ? __pfx_iommufd_fops_ioctl+0x10/0x10
   do_syscall_64+0x3b/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc
References: https://git.kernel.org/stable/c/800963e7eb001ada8cf2418f159fb649694467f1; https://git.kernel.org/stable/c/e[PII_REDACTED]fc4aee[PII_REDACTED]16fe770b81417
CVE: CVE-2023-54240
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()

rule_locs is allocated in ethtool_get_rxnfc and the size is determined by
rule_cnt from user space. So rule_cnt needs to be check before using
rule_locs to avoid NULL pointer dereference.
References: https://git.kernel.org/stable/c/072324cfab9b96071c0782f51f53cc5aea1e9d5b; https://git.kernel.org/stable/c/653fbddbdfc6673bba01b13dae5a4384ad8f92ec; https://git.kernel.org/stable/c/751b2e22a188b0c306029d094da29b6b8de31430
CVE: CVE-2023-54242
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

block, bfq: Fix division by zero error on zero wsum

When the weighted sum is zero the calculation of limit causes
a division by zero error. Fix this by continuing to the next level.

This was discovered by running as root:

stress-ng --ioprio 0

Fixes divison by error oops:

[  521.450556] divide error: 0000 [#1] SMP NOPTI
[  521.450766] CPU: 2 PID: 2684464 Comm: stress-ng-iopri Not tainted 6.2.1-1280.native #1
[  521.451117] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
[  521.451627] RIP: 0010:bfqq_request_over_limit+0x207/0x400
[  521.451875] Code: 01 48 8d 0c c8 74 0b 48 8b 82 98 00 00 00 48 8d 0c c8 8b 85 34 ff ff ff 48 89 ca 41 0f af 41 50 48 d1 ea 48 98 48 01 d0 31 d2 <48> f7 f1 41 39 41 48 89 85 34 ff ff ff 0f 8c 7b 01 00 00 49 8b 44
[  521.452699] RSP: 0018:ffffb1af84eb3948 EFLAGS: 00010046
[  521.452938] RAX:[PII_REDACTED]00003c RBX: [PII_REDACTED] RCX: [PII_REDACTED]
[  521.453262] RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffffb1af84eb3978
[  521.453584] RBP: ffffb1af84eb3a30 R08: [PII_REDACTED] R09: ffff8f88ab8a4ba0
[  521.453905] R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff8f88ab8a4b18
[  521.454224] R13: ffff8f[PII_REDACTED] R14: [PII_REDACTED] R15: ffffb1af84eb3970
[  521.454549] FS:  00005640b6b0b580(0000) GS:ffff8f88b3880000(0000) knlGS:[PII_REDACTED]
[  521.454912] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[  521.455170] CR2: 00007ffcbcae4e38 CR3: 00000002e46de001 CR4:[PII_REDACTED]770ee0
[  521.455491] PKRU: 55555554
[  521.455619] Call Trace:
[  521.455736]  <TASK>
[  521.455837]  ? bfq_request_merge+0x3a/0xc0
[  521.456027]  ? elv_merge+0x115/0x140
[  521.456191]  bfq_limit_depth+0xc8/0x240
[  521.456366]  __blk_mq_alloc_requests+0x21a/0x2c0
[  521.456577]  blk_mq_submit_bio+0x23c/0x6c0
[  521.456766]  __submit_bio+0xb8/0x140
[  521.457236]  submit_bio_noacct_nocheck+0x212/0x300
[  521.457748]  submit_bio_noacct+0x1a6/0x580
[  521.458220]  submit_bio+0x43/0x80
[  521.458660]  ext4_io_submit+0x23/0x80
[  521.459116]  ext4_do_writepages+0x40a/0xd00
[  521.459596]  ext4_writepages+0x65/0x100
[  521.460050]  do_writepages+0xb7/0x1c0
[  521.460492]  __filemap_fdatawrite_range+0xa6/0x100
[  521.460979]  file_write_and_wait_range+0xbf/0x140
[  521.461452]  ext4_sync_file+0x105/0x340
[  521.461882]  __x64_sys_fsync+0x67/0x100
[  521.462305]  ? syscall_exit_to_user_mode+0x2c/0x1c0
[  521.462768]  do_syscall_64+0x3b/0xc0
[  521.463165]  entry_SYSCALL_64_after_hwframe+0x5a/0xc4
[  521.463621] RIP: 0033:0x5640b6c56590
[  521.464006] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 80 3d 71 70 0e 00 00 74 17 b8 4a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
References: https://git.kernel.org/stable/c/1655cfc85250a224b0d9486c8136baeea33b9b5c; https://git.kernel.org/stable/c/c0346a59d719461248c6dc6f21c9e55ef836b66f; https://git.kernel.org/stable/c/e53413f8deedf738a6782cc14cc00bd5852ccf18
CVE: CVE-2023-54243
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: ebtables: fix table blob use-after-free

We are not allowed to return an error at this point.
Looking at the code it looks like ret is always 0 at this
point, but its not.

t = find_table_lock(net, repl->name, &ret, &ebt_mutex);

... this can return a valid table, with ret != 0.

This bug causes update of table->private with the new
blob, but then frees the blob right away in the caller.

Syzbot report:

BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168
Read of size 4 at addr ffffc[PII_REDACTED]0 by task kworker/u4:4/74
Workqueue: netns cleanup_net
Call Trace:
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:517
 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168
 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372
 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169
 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613
...

ip(6)tables appears to be ok (ret should be 0 at this point) but make
this more obvious.
References: https://git.kernel.org/stable/c/3dd6ac973351308d4117eda32298a9f1d68764fd; https://git.kernel.org/stable/c/9060abce3305ab2354c892c09d5689df51486df5; https://git.kernel.org/stable/c/cda0e0243bd3c04008fcd37a46b0269fb3c49249
CVE: CVE-2023-54244
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: EC: Fix oops when removing custom query handlers

When removing custom query handlers, the handler might still
be used inside the EC query workqueue, causing a kernel oops
if the module holding the callback function was already unloaded.

Fix this by flushing the EC query workqueue when removing
custom query handlers.

Tested on a Acer Travelmate 4002WLMi
References: https://git.kernel.org/stable/c/066b90bca755f0b876e7b027b75d1796861d6db0; https://git.kernel.org/stable/c/0d528a7c421b1f1772fc1d29370b3b5fc0f42b19; https://git.kernel.org/stable/c/130e3eac51912f2c866e7d035992ede25f8feac0
CVE: CVE-2023-54245
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: tx-macro: Fix for KASAN: slab-out-of-bounds

When we run syzkaller we get below Out of Bound.
    "KASAN: slab-out-of-bounds Read in regcache_flat_read"

    Below is the backtrace of the issue:

    dump_backtrace+0x0/0x4c8
    show_stack+0x34/0x44
    dump_stack_lvl+0xd8/0x118
    print_address_description+0x30/0x2d8
    kasan_report+0x158/0x198
    __asan_report_load4_noabort+0x44/0x50
    regcache_flat_read+0x10c/0x110
    regcache_read+0xf4/0x180
    _regmap_read+0xc4/0x278
    _regmap_update_bits+0x130/0x290
    regmap_update_bits_base+0xc0/0x15c
    snd_soc_component_update_bits+0xa8/0x22c
    snd_soc_component_write_field+0x68/0xd4
    tx_macro_digital_mute+0xec/0x140

    Actually There is no need to have decimator with 32 bits.
    By limiting the variable with short type u8 issue is resolved.
References: https://git.kernel.org/stable/c/57f9a9a232bde7abfe49c3072b29a255da9ba891; https://git.kernel.org/stable/c/b0cd740a31412340fead50e69e4fe9bc3781c754; https://git.kernel.org/stable/c/da35a4e6eee5d73886312e85322a6e97df901987
CVE: CVE-2023-54246
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

rcuscale: Move rcu_scale_writer() schedule_timeout_uninterruptible() to _idle()

The rcuscale.holdoff module parameter can be used to delay the start
of rcu_scale_writer() kthread.  However, the hung-task timeout will
trigger when the timeout specified by rcuscale.holdoff is greater than
hung_task_timeout_secs:

runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"
bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"

[  247.071753] INFO: task rcu_scale_write:59 blocked for more than 122 seconds.
[  247.072529]       Not tainted 6.4.0-rc1-00134-gb9ed6de8d4ff #7
[  247.073400] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  247.074331] task:rcu_scale_write state:D stack:30144 pid:59    ppid:2      flags:0x00004000
[  247.075346] Call Trace:
[  247.075660]  <TASK>
[  247.075965]  __schedule+0x635/0x1280
[  247.076448]  ? __pfx___schedule+0x10/0x10
[  247.076967]  ? schedule_timeout+0x2dc/0x4d0
[  247.077471]  ? __pfx_lock_release+0x10/0x10
[  247.078018]  ? enqueue_timer+0xe2/0x220
[  247.078522]  schedule+0x84/0x120
[  247.078957]  schedule_timeout+0x2e1/0x4d0
[  247.079447]  ? __pfx_schedule_timeout+0x10/0x10
[  247.080032]  ? __pfx_rcu_scale_writer+0x10/0x10
[  247.080591]  ? __pfx_process_timeout+0x10/0x10
[  247.081163]  ? __pfx_sched_set_fifo_low+0x10/0x10
[  247.081760]  ? __pfx_rcu_scale_writer+0x10/0x10
[  247.082287]  rcu_scale_writer+0x6b1/0x7f0
[  247.082773]  ? mark_held_locks+0x29/0xa0
[  247.083252]  ? __pfx_rcu_scale_writer+0x10/0x10
[  247.083865]  ? __pfx_rcu_scale_writer+0x10/0x10
[  247.084412]  kthread+0x179/0x1c0
[  247.084759]  ? __pfx_kthread+0x10/0x10
[  247.085098]  ret_from_fork+0x2c/0x50
[  247.085433]  </TASK>

This commit therefore replaces schedule_timeout_uninterruptible() with
schedule_timeout_idle().
References: https://git.kernel.org/stable/c/4f03fba096bfded90e0d71eba8839a46922164d1; https://git.kernel.org/stable/c/55887adc76e19aec9763186e2c1d0a3481d20e96; https://git.kernel.org/stable/c/83ed0cdb6ae0383dd14b02375c[PII_REDACTED]84ed
CVE: CVE-2023-54247
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Silence a warning in btf_type_id_size()

syzbot reported a warning in [1] with the following stacktrace:
  WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988
  ...
  RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988
  ...
  Call Trace:
   <TASK>
   map_check_btf kernel/bpf/syscall.c:1024 [inline]
   map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198
   __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040
   __do_sys_bpf kernel/bpf/syscall.c:5162 [inline]
   __se_sys_bpf kernel/bpf/syscall.c:5160 [inline]
   __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160
   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
   do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd

With the following btf
  [1] DECL_TAG 'a' type_id=4 component_idx=-1
  [2] PTR '(anon)' type_id=0
  [3] TYPE_TAG 'a' type_id=2
  [4] VAR 'a' type_id=3, linkage=static
and when the bpf_attr.btf_key_type_id = 1 (DECL_TAG),
the following WARN_ON_ONCE in btf_type_id_size() is triggered:
  if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) &&
                   !btf_type_is_var(size_type)))
          return NULL;

Note that 'return NULL' is the correct behavior as we don't want
a DECL_TAG type to be used as a btf_{key,value}_type_id even
for the case like 'DECL_TAG -> STRUCT'. So there
is no correctness issue here, we just want to silence warning.

To silence the warning, I added DECL_TAG as one of kinds in
btf_type_nosize() which will cause btf_type_id_size() returning
NULL earlier without the warning.

  [1] https://lore.kernel.org/bpf/[PII_REDACTED]00e0df8d05fc75ba86@google.com/
References: https://git.kernel.org/stable/c/61f4bd46a03a81865aca3bcbad2f7b7032fb3160; https://git.kernel.org/stable/c/7c4f5ab63e[PII_REDACTED]cbd38cc765168a223acb; https://git.kernel.org/stable/c/e6c2f594ed[PII_REDACTED]05b[PII_REDACTED]0190305
CVE: CVE-2023-54248
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Add check for kmemdup

Since the kmemdup may return NULL pointer,
it should be better to add check for the return value
in order to avoid NULL pointer dereference.
References: https://git.kernel.org/stable/c/7898db22ed6cee909513cf4935b5f9f0298b74f0; https://git.kernel.org/stable/c/952bbfcedbf[PII_REDACTED]61e55a6e4fc105eb842; https://git.kernel.org/stable/c/9f36704a58adade3b0216f8a3fa5503db4517208
CVE: CVE-2023-54249
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

bus: mhi: ep: Only send -ENOTCONN status if client driver is available

For the STOP and RESET commands, only send the channel disconnect status
-ENOTCONN if client driver is available. Otherwise, it will result in
null pointer dereference.
References: https://git.kernel.org/stable/c/353aea15d6edbd4e69e039356a1bd3e641f7d952; https://git.kernel.org/stable/c/860ad591056d7e4dc30bc130b6ec6e6d70930c85; https://git.kernel.org/stable/c/e6cebcc27519dcf1652e604c73b9fd4f416987c0
CVE: CVE-2023-54250
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: avoid out of bounds access in decode_preauth_ctxt()

Confirm that the accessed pneg_ctxt->HashAlgorithms address sits within
the SMB request boundary; deassemble_neg_contexts() only checks that the
eight byte smb2_neg_context header + (client controlled) DataLength are
within the packet boundary, which is insufficient.

Checking for sizeof(struct smb2_preauth_neg_context) is overkill given
that the type currently assumes SMB311_SALT_SIZE bytes of trailing Salt.
References: https://git.kernel.org/stable/c/39f5b4b313b445c980a2a295bed28228c29228ed; https://git.kernel.org/stable/c/a2f6ded41bec1d3be643c80a5eb97f[PII_REDACTED]; https://git.kernel.org/stable/c/e7067a446264a7514fa1cfaa4052cdb6803bc6a2
CVE: CVE-2023-54252
Published: 2025-12-30
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: think-lmi: Fix memory leaks when parsing ThinkStation WMI strings

My previous commit introduced a memory leak where the item allocated
from tlmi_setting was not freed.
This commit also renames it to avoid confusion with the similarly name
variable in the same function.
References: https://git.kernel.org/stable/c/081da7b1c881828244b93b3befb7c18389f696bb; https://git.kernel.org/stable/c/43fc0342bac1808fda2b76184e[PII_REDACTED]1c6b; https://git.kernel.org/stable/c/cccdb30935c82be805d3362a15680b95d5cb3ee0