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

media: platform: mtk-mdp3: Add missing check and free for ida_alloc

Add the check for the return value of the ida_alloc in order to avoid
NULL pointer dereference.
Moreover, free allocated "ctx->id" if mdp_m2m_open fails later in order
to avoid memory leak.
References: https://git.kernel.org/stable/c/22b72cad501fb75500cc60af4d92de3066fb6fc2; https://git.kernel.org/stable/c/4c173a65a2b1cc0556c3f6f0bab82e4fdb449522; https://git.kernel.org/stable/c/51fc1880e47421ee7b192372e8e86b7bbba40776
CVE: CVE-2023-54149
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addresses

When using the felix driver (the only one which supports UC filtering
and MC filtering) as a DSA master for a random other DSA switch, one can
see the following stack trace when the downstream switch ports join a
VLAN-aware bridge:

=============================
WARNING: suspicious RCU usage
-----------------------------
net/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage!

stack backtrace:
Workqueue: dsa_ordered dsa_slave_switchdev_event_work
Call trace:
 lockdep_rcu_suspicious+0x170/0x210
 vlan_for_each+0x8c/0x188
 dsa_slave_sync_uc+0x128/0x178
 __hw_addr_sync_dev+0x138/0x158
 dsa_slave_set_rx_mode+0x58/0x70
 __dev_set_rx_mode+0x88/0xa8
 dev_uc_add+0x74/0xa0
 dsa_port_bridge_host_fdb_add+0xec/0x180
 dsa_slave_switchdev_event_work+0x7c/0x1c8
 process_one_work+0x290/0x568

What it's saying is that vlan_for_each() expects rtnl_lock() context and
it's not getting it, when it's called from the DSA master's ndo_set_rx_mode().

The caller of that - dsa_slave_set_rx_mode() - is the slave DSA
interface's dsa_port_bridge_host_fdb_add() which comes from the deferred
dsa_slave_switchdev_event_work().

We went to great lengths to avoid the rtnl_lock() context in that call
path in commit 0faf890fc519 ("net: dsa: drop rtnl_lock from
dsa_slave_switchdev_event_work"), and calling rtnl_lock() is simply not
an option due to the possibility of deadlocking when calling
dsa_flush_workqueue() from the call paths that do hold rtnl_lock() -
basically all of them.

So, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(),
the state of the 8021q driver on this device is really not protected
from concurrent access by anything.

Looking at net/8021q/, I don't think that vlan_info->vid_list was
particularly designed with RCU traversal in mind, so introducing an RCU
read-side form of vlan_for_each() - vlan_for_each_rcu() - won't be so
easy, and it also wouldn't be exactly what we need anyway.

In general I believe that the solution isn't in net/8021q/ anyway;
vlan_for_each() is not cut out for this task. DSA doesn't need rtnl_lock()
to be held per se - since it's not a netdev state change that we're
blocking, but rather, just concurrent additions/removals to a VLAN list.
We don't even need sleepable context - the callback of vlan_for_each()
just schedules deferred work.

The proposed escape is to remove the dependency on vlan_for_each() and
to open-code a non-sleepable, rtnl-free alternative to that, based on
copies of the VLAN list modified from .ndo_vlan_rx_add_vid() and
.ndo_vlan_rx_kill_vid().
References: https://git.kernel.org/stable/c/3948c69b3837fec2ee5a90fbc911c343199be0ac; https://git.kernel.org/stable/c/3f9e79f31e51b7d5bf95c617540deb6cf2816a3f; https://git.kernel.org/stable/c/d06f925f13976ab82167c93467c70a337a0a3cda
CVE: CVE-2023-54150
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd: Fix an out of bounds error in BIOS parser

The array is hardcoded to 8 in atomfirmware.h, but firmware provides
a bigger one sometimes. Deferencing the larger array causes an out
of bounds error.

commit 4fc1ba4aa589 ("drm/amd/display: fix array index out of bound error
in bios parser") fixed some of this, but there are two other cases
not covered by it.  Fix those as well.
References: https://git.kernel.org/stable/c/5675ecd2e0b00a4318ba1db1a1234e7d45b13d6b; https://git.kernel.org/stable/c/66acfe798cd08b36cfbb65a30fab[PII_REDACTED]a7; https://git.kernel.org/stable/c/b8e7589f50b709b647b642531599e70707faf70c
CVE: CVE-2023-54151
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: Fix system crash due to lack of free space in LFS

When f2fs tries to checkpoint during foreground gc in LFS mode, system
crash occurs due to lack of free space if the amount of dirty node and
dentry pages generated by data migration exceeds free space.
The reproduction sequence is as follows.

 - 20GiB capacity block device (null_blk)
 - format and mount with LFS mode
 - create a file and write 20,000MiB
 - 4k random write on full range of the file

 RIP: 0010:new_curseg+0x48a/0x510 [f2fs]
 Code: 55 e7 f5 89 c0 48 0f af c3 48 8b 5d c0 48 c1 e8 20 83 c0 01 89 43 6c 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc <0f> 0b f0 41 80 4f 48 04 45 85 f6 0f 84 ba fd ff ff e9 ef fe ff ff
 RSP: 0018:ffff977bc397b218 EFLAGS: 00010246
 RAX:[PII_REDACTED]0027b9 RBX: [PII_REDACTED] RCX:[PII_REDACTED]0027c0
 RDX: [PII_REDACTED] RSI:[PII_REDACTED]0027b9 RDI: ffff8c25ab4e74f8
 RBP: ffff977bc397b268 R08:[PII_REDACTED]0027b9 R09: ffff8c29e4a34b40
 R10: [PII_REDACTED] R11: ffff977bc397b0d8 R12: [PII_REDACTED]
 R13: ffff8c25b4dd81a0 R14: [PII_REDACTED] R15: ffff8c2f667f9000
 FS: [PII_REDACTED](0000) GS:ffff8c344ec80000(0000) knlGS:[PII_REDACTED]
 CS: 0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: 000000c00055d000 CR3: 0000000e30810003 CR4:[PII_REDACTED]3706e0
 DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
 DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
 Call Trace:
 <TASK>
 allocate_segment_by_default+0x9c/0x110 [f2fs]
 f2fs_allocate_data_block+0x243/0xa30 [f2fs]
 ? __mod_lruvec_page_state+0xa0/0x150
 do_write_page+0x80/0x160 [f2fs]
 f2fs_do_write_node_page+0x32/0x50 [f2fs]
 __write_node_page+0x339/0x730 [f2fs]
 f2fs_sync_node_pages+0x5a6/0x780 [f2fs]
 block_operations+0x257/0x340 [f2fs]
 f2fs_write_checkpoint+0x102/0x1050 [f2fs]
 f2fs_gc+0x27c/0x630 [f2fs]
 ? folio_mark_dirty+0x36/0x70
 f2fs_balance_fs+0x16f/0x180 [f2fs]

This patch adds checking whether free sections are enough before checkpoint
during gc.

[Jaegeuk Kim: code clean-up]
References: https://git.kernel.org/stable/c/ce71c61d661cfac3f097af928995abfcebd2b8c5; https://git.kernel.org/stable/c/d11cef14f8146f3babd286c2cc8ca09c166295e2; https://git.kernel.org/stable/c/f4631d295ae3fff9e240ab78dc17f4b83d14f7bc
CVE: CVE-2023-54152
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

can: j1939: prevent deadlock by moving j1939_sk_errqueue()

This commit addresses a deadlock situation that can occur in certain
scenarios, such as when running data TP/ETP transfer and subscribing to
the error queue while receiving a net down event. The deadlock involves
locks in the following order:

3
  j1939_session_list_lock ->  active_session_list_lock
  j1939_session_activate
  ...
  j1939_sk_queue_activate_next -> sk_session_queue_lock
  ...
  j1939_xtp_rx_eoma_one

2
  j1939_sk_queue_drop_all  ->  sk_session_queue_lock
  ...
  j1939_sk_netdev_event_netdown -> j1939_socks_lock
  j1939_netdev_notify

1
  j1939_sk_errqueue -> j1939_socks_lock
  __j1939_session_cancel -> active_session_list_lock
  j1939_tp_rxtimer

       CPU0                    CPU1
       ----                    ----
  lock(&priv->active_session_list_lock);
                               lock(&jsk->sk_session_queue_lock);
                               lock(&priv->active_session_list_lock);
  lock(&priv->j1939_socks_lock);

The solution implemented in this commit is to move the
j1939_sk_errqueue() call out of the active_session_list_lock context,
thus preventing the deadlock situation.
References: https://git.kernel.org/stable/c/8a581b71cf686b4cd1a85c9c2dfc2fb88382c3b4; https://git.kernel.org/stable/c/ace6aa2ab5ba5869563ca689bbd912100514ae7b; https://git.kernel.org/stable/c/d1366b283d94ac4537a4b3a1e8668da4df7ce7e9
CVE: CVE-2023-54153
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: turn quotas off if mount failed after enabling quotas

Yi found during a review of the patch "ext4: don't BUG on inconsistent
journal feature" that when ext4_mark_recovery_complete() returns an error
value, the error handling path does not turn off the enabled quotas,
which triggers the following kmemleak:

================================================================
unreferenced object 0xffff8cf68678e7c0 (size 64):
comm "mount", pid 746, jiffies[PII_REDACTED] (age 11.540s)
hex dump (first 32 bytes):
00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00  ............A...
c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00  ............H...
backtrace:
[<00000000c561ef24>] __kmem_cache_alloc_node+0x4d4/0x880
[<00000000d4e621d7>] kmalloc_trace+0x39/0x140
[<[PII_REDACTED]7eee74>] v2_read_file_info+0x18a/0x3a0
[<[PII_REDACTED]f6c877>] dquot_load_quota_sb+0x2ed/0x770
[<[PII_REDACTED]0a4782>] dquot_load_quota_inode+0xc6/0x1c0
[<[PII_REDACTED]a18bd5>] ext4_enable_quotas+0x17e/0x3a0 [ext4]
[<000000003a0268fa>] __ext4_fill_super+0x3448/0x3910 [ext4]
[<00000000b0f2a8a8>] ext4_fill_super+0x13d/0x340 [ext4]
[<000000004a9489c4>] get_tree_bdev+0x1dc/0x370
[<000000006e723bf1>] ext4_get_tree+0x1d/0x30 [ext4]
[<00000000c7cb663d>] vfs_get_tree+0x31/0x160
[<[PII_REDACTED]0e1bed>] do_new_mount+0x1d5/0x480
[<00000000c074654c>] path_mount+0x22e/0xbe0
[<[PII_REDACTED]e97a8e>] do_mount+0x95/0xc0
[<000000002f3d3736>] __x64_sys_mount+0xc4/0x160
[<[PII_REDACTED]d2140c>] do_syscall_64+0x3f/0x90
================================================================

To solve this problem, we add a "failed_mount10" tag, and call
ext4_quota_off_umount() in this tag to release the enabled qoutas.
References: https://git.kernel.org/stable/c/77c3ca1108eb4a26db4f256c42b271a430cebc7d; https://git.kernel.org/stable/c/c327b83c59ee938792a0300df646efac39c7d6a7; https://git.kernel.org/stable/c/d13f[PII_REDACTED]2c32fc95d729f5e754bab06064
CVE: CVE-2023-54154
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: target: core: Fix target_cmd_counter leak

The target_cmd_counter struct allocated via target_alloc_cmd_counter() is
never freed, resulting in leaks across various transport types, e.g.:

 unreferenced object 0xffff88801f920120 (size 96):
  comm "sh", pid 102, jiffies[PII_REDACTED] (age 713.412s)
  hex dump (first 32 bytes):
    07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 38 01 92 1f 80 88 ff ff  ........8.......
  backtrace:
    [<00000000e58a6252>] kmalloc_trace+0x11/0x20
    [<[PII_REDACTED]af4b2f>] target_alloc_cmd_counter+0x17/0x90 [target_core_mod]
    [<000000007da2dfa7>] target_setup_session+0x2d/0x140 [target_core_mod]
    [<[PII_REDACTED]feef86>] tcm_loop_tpg_nexus_store+0x19b/0x350 [tcm_loop]
    [<000000006a80e021>] configfs_write_iter+0xb1/0x120
    [<00000000e9f4d860>] vfs_write+0x2e4/0x3c0
    [<[PII_REDACTED]43433b>] ksys_write+0x80/0xb0
    [<00000000a7df29b2>] do_syscall_64+0x42/0x90
    [<[PII_REDACTED]f45fb8>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Free the structure alongside the corresponding iscsit_conn / se_sess
parent.
References: https://git.kernel.org/stable/c/1cd41d1669bcbc5052afa897f85608a62ff3fb30; https://git.kernel.org/stable/c/d14e3e553e05cb763964c991fe6acb0a6a1c6f9c; https://git.kernel.org/stable/c/f84639c5ac5f4f95b3992da1af4ff382ebf2e819
CVE: CVE-2023-54155
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail()

Syzkaller reported the following issue:
=======================================
Too BIG xdp->frame_sz = 131072
WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121
  ____bpf_xdp_adjust_tail net/core/filter.c:4121 [inline]
WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121
  bpf_xdp_adjust_tail+0x466/0xa10 net/core/filter.c:4103
...
Call Trace:
 <TASK>
 bpf_prog_4add87e5301a4105+0x1a/0x1c
 __bpf_prog_run include/linux/filter.h:600 [inline]
 bpf_prog_run_xdp include/linux/filter.h:775 [inline]
 bpf_prog_run_generic_xdp+0x57e/0x11e0 net/core/dev.c:4721
 netif_receive_generic_xdp net/core/dev.c:4807 [inline]
 do_xdp_generic+0x35c/0x770 net/core/dev.c:4866
 tun_get_user+0x2340/0x3ca0 drivers/net/tun.c:1919
 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2043
 call_write_iter include/linux/fs.h:1871 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x650/0xe40 fs/read_write.c:584
 ksys_write+0x12f/0x250 fs/read_write.c:637
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

xdp->frame_sz > PAGE_SIZE check was introduced in commit c8741e2bfe87
("xdp: Allow bpf_xdp_adjust_tail() to grow packet size"). But Jesper
Dangaard Brouer <jbrouer@redhat.com> noted that after introducing the
xdp_init_buff() which all XDP driver use - it's safe to remove this
check. The original intend was to catch cases where XDP drivers have
not been updated to use xdp.frame_sz, but that is not longer a concern
(since xdp_init_buff).

Running the initial syzkaller repro it was discovered that the
contiguous physical memory allocation is used for both xdp paths in
tun_get_user(), e.g. tun_build_skb() and tun_alloc_skb(). It was also
stated by Jesper Dangaard Brouer <jbrouer@redhat.com> that XDP can
work on higher order pages, as long as this is contiguous physical
memory (e.g. a page).
References: https://git.kernel.org/stable/c/20acffcdc2b74fb7dcc4e299f7aca173df89d911; https://git.kernel.org/stable/c/a09c258cfa77d3ba0a7acc555c73eb6b005c4bd8; https://git.kernel.org/stable/c/d14eea09edf427fa36bd446f4a3271f99164202f
CVE: CVE-2023-54156
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

sfc: fix crash when reading stats while NIC is resetting

efx_net_stats() (.ndo_get_stats64) can be called during an ethtool
 selftest, during which time nic_data->mc_stats is NULL as the NIC has
 been fini'd.  In this case do not attempt to fetch the latest stats
 from the hardware, else we will crash on a NULL dereference:
    BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    RIP efx_nic_update_stats
    abridged calltrace:
    efx_ef10_update_stats_pf
    efx_net_stats
    dev_get_stats
    dev_seq_printf_stats
Skipping the read is safe, we will simply give out stale stats.
To ensure that the free in efx_ef10_fini_nic() does not race against
 efx_ef10_update_stats_pf(), which could cause a TOCTTOU bug, take the
 efx->stats_lock in fini_nic (it is already held across update_stats).
References: https://git.kernel.org/stable/c/446f[PII_REDACTED]923d0aec4ce045e4ecb0174aae; https://git.kernel.org/stable/c/470152d76b3ed107d172ea46acc4bfa941f20b4b; https://git.kernel.org/stable/c/91f4ef204e731565afdc6c2a7fcf509a3fd6fd67
CVE: CVE-2023-54158
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: don't free qgroup space unless specified

Boris noticed in his simple quotas testing that he was getting a leak
with Sweet Tea's change to subvol create that stopped doing a
transaction commit.  This was just a side effect of that change.

In the delayed inode code we have an optimization that will free extra
reservations if we think we can pack a dir item into an already modified
leaf.  Previously this wouldn't be triggered in the subvolume create
case because we'd commit the transaction, it was still possible but
much harder to trigger.  It could actually be triggered if we did a
mkdir && subvol create with qgroups enabled.

This occurs because in btrfs_insert_delayed_dir_index(), which gets
called when we're adding the dir item, we do the following:

  btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);

if we're able to skip reserving space.

The problem here is that trans->block_rsv points at the temporary block
rsv for the subvolume create, which has qgroup reservations in the block
rsv.

This is a problem because btrfs_block_rsv_release() will do the
following:

  if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) {
	  qgroup_to_release = block_rsv->qgroup_rsv_reserved -
		  block_rsv->qgroup_rsv_size;
	  block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size;
  }

The temporary block rsv just has ->qgroup_rsv_reserved set,
->qgroup_rsv_size == 0.  The optimization in
btrfs_insert_delayed_dir_index() sets ->qgroup_rsv_reserved = 0.  Then
later on when we call btrfs_subvolume_release_metadata() which has

  btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release);
  btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);

qgroup_to_release is set to 0, and we do not convert the reserved
metadata space.

The problem here is that the block rsv code has been unconditionally
messing with ->qgroup_rsv_reserved, because the main place this is used
is delalloc, and any time we call btrfs_block_rsv_release() we do it
with qgroup_to_release set, and thus do the proper accounting.

The subvolume code is the only other code that uses the qgroup
reservation stuff, but it's intermingled with the above optimization,
and thus was getting its reservation freed out from underneath it and
thus leaking the reserved space.

The solution is to simply not mess with the qgroup reservations if we
don't have qgroup_to_release set.  This works with the existing code as
anything that messes with the delalloc reservations always have
qgroup_to_release set.  This fixes the leak that Boris was observing.
References: https://git.kernel.org/stable/c/04ff6bd[PII_REDACTED]ef3e443c7c89f3c0dda548d; https://git.kernel.org/stable/c/148b16cd30b202999ec5b534e3e5d8ab4b766f21; https://git.kernel.org/stable/c/15e877e5923ec6d6caa5e447dcc4b79a8ff7cc53
CVE: CVE-2023-54159
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: mtu3: fix kernel panic at qmu transfer done irq handler

When handle qmu transfer irq, it will unlock @mtu->lock before give back
request, if another thread handle disconnect event at the same time, and
try to disable ep, it may lock @mtu->lock and free qmu ring, then qmu
irq hanlder may get a NULL gpd, avoid the KE by checking gpd's value before
handling it.

e.g.
qmu done irq on cpu0                 thread running on cpu1

qmu_done_tx()
  handle gpd [0]
    mtu3_requ_complete()        mtu3_gadget_ep_disable()
      unlock @mtu->lock
        give back request         lock @mtu->lock
                                    mtu3_ep_disable()
                                      mtu3_gpd_ring_free()
                                   unlock @mtu->lock
      lock @mtu->lock
    get next gpd [1]

[1]: goto [0] to handle next gpd, and next gpd may be NULL.
References: https://git.kernel.org/stable/c/012936502a9cb7b0604e85bb961eb15e2bb40dd9; https://git.kernel.org/stable/c/26ca30516b2c49dd04c134cbdf122311c538df98; https://git.kernel.org/stable/c/3a7d4959560a2ee493ef222e3b63d359365f41ec
CVE: CVE-2023-54160
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_sdei: Fix sleep from invalid context BUG

Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra
triggers:

  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
  in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0
  preempt_count: 0, expected: 0
  RCU nest depth: 0, expected: 0
  3 locks held by cpuhp/0/24:
    #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248
    #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248
    #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130
  irq event stamp: 36
  hardirqs last  enabled at (35): [<ffffda301e85b7bc>] finish_task_switch+0xb4/0x2b0
  hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhp_thread_fun+0x21c/0x248
  softirqs last  enabled at (0): [<ffffda301e80b184>] copy_process+0x63c/0x1ac0
  softirqs last disabled at (0): [<[PII_REDACTED]>] 0x0
  CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...]
  Hardware name: WIWYNN Mt.Jade Server [...]
  Call trace:
    dump_backtrace+0x114/0x120
    show_stack+0x20/0x70
    dump_stack_lvl+0x9c/0xd8
    dump_stack+0x18/0x34
    __might_resched+0x188/0x228
    rt_spin_lock+0x70/0x120
    sdei_cpuhp_up+0x3c/0x130
    cpuhp_invoke_callback+0x250/0xf08
    cpuhp_thread_fun+0x120/0x248
    smpboot_thread_fn+0x280/0x320
    kthread+0x130/0x140
    ret_from_fork+0x10/0x20

sdei_cpuhp_up() is called in the STARTING hotplug section,
which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entry
instead to execute the cpuhp cb later, with preemption enabled.

SDEI originally got its own cpuhp slot to allow interacting
with perf. It got superseded by pNMI and this early slot is not
relevant anymore. [1]

Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on the
calling CPU. It is checked that preemption is disabled for them.
_ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.
Preemption is enabled in those threads, but their cpumask is limited
to 1 CPU.
Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cb
don't trigger them.

Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI call
which acts on the calling CPU.

[1]:
https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/
References: https://git.kernel.org/stable/c/18d5ea5b746120a3972e6c347ad[PII_REDACTED]327; https://git.kernel.org/stable/c/48ac727ea4a3577eb1b4e24f807ba532c47930f9; https://git.kernel.org/stable/c/59842a9ba27d5390ae5bf3233a92cad3a26d495c
CVE: CVE-2023-54161
Published: 2025-12-24
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-67621
Published: 2025-12-24
Description: Exposure of Sensitive System Information to an Unauthorized Control Sphere vulnerability in 10up Eight Day Week Print Workflow eight-day-week-print-workflow allows Retrieve Embedded Sensitive Data.This issue affects Eight Day Week Print Workflow: from n/a through <= 1.2.5.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-497
References: https://patchstack.com/database/Wordpress/Plugin/eight-day-week-print-workflow/vulnerability/wordpress-eight-day-week-print-workflow-plugin-1-2-5-sensitive-data-exposure-vulnerability?_s_id=cve
CVE: CVE-2025-67622
Published: 2025-12-24
Description: Cross-Site Request Forgery (CSRF) vulnerability in titopandub Evergreen Post Tweeter evergreen-post-tweeter allows Stored XSS.This issue affects Evergreen Post Tweeter: from n/a through <= 1.8.9.
CVSS Score: 7.1 (HIGH)
CWE: CWE-352
References: https://patchstack.com/database/Wordpress/Plugin/evergreen-post-tweeter/vulnerability/wordpress-evergreen-post-tweeter-plugin-1-8-9-cross-site-request-forgery-csrf-to-stored-xss-vulnerability?_s_id=cve
CVE: CVE-2025-67623
Published: 2025-12-24
Description: Server-Side Request Forgery (SSRF) vulnerability in 6Storage 6Storage Rentals 6storage-rentals allows Server Side Request Forgery.This issue affects 6Storage Rentals: from n/a through <= 2.22.0.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-918
References: https://patchstack.com/database/Wordpress/Plugin/6storage-rentals/vulnerability/wordpress-6storage-rentals-plugin-2-19-9-server-side-request-forgery-ssrf-vulnerability?_s_id=cve
CVE: CVE-2025-67625
Published: 2025-12-24
Description: Cross-Site Request Forgery (CSRF) vulnerability in tmtraderunner Trade Runner traderunner allows Cross Site Request Forgery.This issue affects Trade Runner: from n/a through <= 3.14.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-352
References: https://patchstack.com/database/Wordpress/Plugin/traderunner/vulnerability/wordpress-trade-runner-plugin-3-14-cross-site-request-forgery-csrf-vulnerability?_s_id=cve