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

ipv6: use RCU in ip6_xmit()

Use RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent
possible UAF.
References: https://git.kernel.org/stable/c/9085e56501d93af9f2d7bd16f7fcfacdde47b99c; https://git.kernel.org/stable/c/bd0905e2122e3680968cd[PII_REDACTED]490bf2ed3; https://git.kernel.org/stable/c/f0a54d00d2f36de40266f47c27989853e8588656
CVE: CVE-2025-40136
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/qm - request reserved interrupt for virtual function

The device interrupt vector 3 is an error interrupt for
physical function and a reserved interrupt for virtual function.
However, the driver has not registered the reserved interrupt for
virtual function. When allocating interrupts, the number of interrupts
is allocated based on powers of two, which includes this interrupt.
When the system enables GICv4 and the virtual function passthrough
to the virtual machine, releasing the interrupt in the driver
triggers a warning.

The WARNING report is:
WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4

Therefore, register a reserved interrupt for VF and set the
IRQF_NO_AUTOEN flag to avoid that warning.
References: https://git.kernel.org/stable/c/854da2b0df1654d63963d587b12fec6068d89643; https://git.kernel.org/stable/c/9228facb308157ac0bdd264b873187896f7a9c7a
CVE: CVE-2025-40137
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to truncate first page in error path of f2fs_truncate()

syzbot reports a bug as below:

loop0: detected capacity change from 0 to 40427
F2FS-fs (loop0): Wrong SSA boundary, start(3584) end(4096) blocks(3072)
F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (loop0): invalid crc value
F2FS-fs (loop0): f2fs_convert_inline_folio: corrupted inline inode ino=3, i_addr[0]:0x1601, run fsck to fix.
------------[ cut here ]------------
kernel BUG at fs/inode.c:753!
RIP: 0010:clear_inode+0x169/0x190 fs/inode.c:753
Call Trace:
 <TASK>
 evict+0x504/0x9c0 fs/inode.c:810
 f2fs_fill_super+0x5612/0x6fa0 fs/f2fs/super.c:5047
 get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1692
 vfs_get_tree+0x8f/0x2b0 fs/super.c:1815
 do_new_mount+0x2a2/0x9e0 fs/namespace.c:3808
 do_mount fs/namespace.c:4136 [inline]
 __do_sys_mount fs/namespace.c:4347 [inline]
 __se_sys_mount+0x317/0x410 fs/namespace.c:4324
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

During f2fs_evict_inode(), clear_inode() detects that we missed to truncate
all page cache before destorying inode, that is because in below path, we
will create page #0 in cache, but missed to drop it in error path, let's fix
it.

- evict
 - f2fs_evict_inode
  - f2fs_truncate
   - f2fs_convert_inline_inode
    - f2fs_grab_cache_folio
    : create page #0 in cache
    - f2fs_convert_inline_folio
    : sanity check failed, return -EFSCORRUPTED
  - clear_inode detects that inode->i_data.nrpages is not zero
References: https://git.kernel.org/stable/c/3b0c8908faa18cded84d64822882a830ab1f4d26; https://git.kernel.org/stable/c/83a8e4efea022506a0e049e7206bdf8be9f78148; https://git.kernel.org/stable/c/9251a9e6e871cb03c4714a18efa8f5d4a8818450
CVE: CVE-2025-40138
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency()

syzbot reported a f2fs bug as below:

Oops: gen[  107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000000-0x[PII_REDACTED]000007]
CPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G        W           6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT_{RT,(full)}
RIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284
Call Trace:
 <TASK>
 f2fs_check_quota_consistency fs/f2fs/super.c:1188 [inline]
 f2fs_check_opt_consistency+0x1378/0x2c10 fs/f2fs/super.c:1436
 __f2fs_remount fs/f2fs/super.c:2653 [inline]
 f2fs_reconfigure+0x482/0x1770 fs/f2fs/super.c:5297
 reconfigure_super+0x224/0x890 fs/super.c:1077
 do_remount fs/namespace.c:3314 [inline]
 path_mount+0xd18/0xfe0 fs/namespace.c:4112
 do_mount fs/namespace.c:4133 [inline]
 __do_sys_mount fs/namespace.c:4344 [inline]
 __se_sys_mount+0x317/0x410 fs/namespace.c:4321
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The direct reason is f2fs_check_quota_consistency() may suffer null-ptr-deref
issue in strcmp().

The bug can be reproduced w/ below scripts:
mkfs.f2fs -f /dev/vdb
mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs
quotacheck -uc /mnt/f2fs/
umount /mnt/f2fs
mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs
mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs
umount /mnt/f2fs

So, before old_qname and new_qname comparison, we need to check whether
they are all valid pointers, fix it.
References: https://git.kernel.org/stable/c/3f3458852bbfe79c60f2412b8b04677b96688b6e; https://git.kernel.org/stable/c/930a9a6ee8e7ffa20af4bffbfc2bbd21d83bf81c
CVE: CVE-2025-40139
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().

smc_clc_prfx_set() is called during connect() and not under RCU
nor RTNL.

Using sk_dst_get(sk)->dev could trigger UAF.

Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()
after kernel_getsockname().

Note that the returned value of smc_clc_prfx_set() is not used
in the caller.

While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()
not to touch dst there.
References: https://git.kernel.org/stable/c/0736993bfe5c7a9c744ae3fac62d769dfdae54e1; https://git.kernel.org/stable/c/935d783e5de9b64587f3adb25641dd8385e64ddb
CVE: CVE-2025-40140
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast

syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.
This is the sequence of events that leads to the warning:

rtl8150_start_xmit() {
	netif_stop_queue();
	usb_submit_urb(dev->tx_urb);
}

rtl8150_set_multicast() {
	netif_stop_queue();
	netif_wake_queue();		<-- wakes up TX queue before URB is done
}

rtl8150_start_xmit() {
	netif_stop_queue();
	usb_submit_urb(dev->tx_urb);	<-- double submission
}

rtl8150_set_multicast being the ndo_set_rx_mode callback should not be
calling netif_stop_queue and notif_start_queue as these handle
TX queue synchronization.

The net core function dev_set_rx_mode handles the synchronization
for rtl8150_set_multicast making it safe to remove these locks.
References: https://git.kernel.org/stable/c/114e05344763a102a8844efd96ec06ba99293ccd; https://git.kernel.org/stable/c/1a08a37ac03d07a1608a[PII_REDACTED]cac979fbc3; https://git.kernel.org/stable/c/54f8ef1a970a8376e5846ed90854decf7c00555d
CVE: CVE-2025-40141
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: ISO: Fix possible UAF on iso_conn_free

This attempt to fix similar issue to sco_conn_free where if the
conn->sk is not set to NULL may lead to UAF on iso_conn_free.
References: https://git.kernel.org/stable/c/5319145a07d8bf5b0782b25cb[PII_REDACTED]d42bb; https://git.kernel.org/stable/c/[PII_REDACTED]9f02328eb873769de4647c9dd3e371; https://git.kernel.org/stable/c/9950f095d6c875dbe0c9ebfcf972ec88fdf26fc8
CVE: CVE-2025-40142
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT

snd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts
via spin_lock_irq(). This also implicitly disables the handling of
softirqs such as TIMER_SOFTIRQ.
On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not
disable them. That means a timer can be invoked during spin_lock_irq()
on the same CPU. Due to synchronisations reasons local_bh_disable() has
a per-CPU lock named softirq_ctrl.lock which synchronizes individual
softirq against each other.
syz-bot managed to trigger a lockdep report where softirq_ctrl.lock is
acquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This
is a possible deadlock.

The softirq_ctrl.lock can not be made part of spin_lock_irq() as this
would lead to too much synchronisation against individual threads on the
system. To avoid the possible deadlock, softirqs must be manually
disabled before the lock is acquired.

Disable softirqs before the lock is acquired on PREEMPT_RT.
References: https://git.kernel.org/stable/c/3969b6193cb7a45aa5fb4ec68f215e9e7f93d39a; https://git.kernel.org/stable/c/63ee96c7f47df239ee0a6e8108b6bfd8c98334ae; https://git.kernel.org/stable/c/9fc4a3da9a0259a0500848b5d8657918efde176b
CVE: CVE-2025-40143
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: dont report verifier bug for missing bpf_scc_visit on speculative path

Syzbot generated a program that triggers a verifier_bug() call in
maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a
state with insn_idx in some SCC, there should be an instance of struct
bpf_scc_visit allocated for that SCC. Turns out the assumption does
not hold for speculative execution paths. See example in the next
patch.

maybe_scc_exit() is called from update_branch_counts() for states that
reach branch count of zero, meaning that path exploration for a
particular path is finished. Path exploration can finish in one of
three ways:
a. Verification error is found. In this case, update_branch_counts()
   is called only for non-speculative paths.
b. Top level BPF_EXIT is reached. Such instructions are never a part of
   an SCC, so compute_scc_callchain() in maybe_scc_exit() will return
   false, and maybe_scc_exit() will return early.
c. A checkpoint is reached and matched. Checkpoints are created by
   is_state_visited(), which calls maybe_enter_scc(), which allocates
   bpf_scc_visit instances for checkpoints within SCCs.

Hence, for non-speculative symbolic execution paths, the assumption
still holds: if maybe_scc_exit() is called for a state within an SCC,
bpf_scc_visit instance must exist.

This patch removes the verifier_bug() call for speculative paths.
References: https://git.kernel.org/stable/c/3861e7c4324aa20a632fb74eb3904114f6afdb57; https://git.kernel.org/stable/c/a3c73d629ea1373af3c0c954d41fd1af555492e3
CVE: CVE-2025-40144
Published: 2025-11-12
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-40145
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure

When devm_add_action_or_reset() fails, it calls the passed cleanup
function.  Hence the caller must not repeat that cleanup.

Replace the "goto err_regulator_free" by the actual freeing, as there
will never be a need again for a second user of this label.
References: https://git.kernel.org/stable/c/77732c58fef6247b71493dc3997af0ec0aaad5c7; https://git.kernel.org/stable/c/ab81f2f79c683c94bac622aafafbe8232e547159
CVE: CVE-2025-40146
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: fix potential deadlock while nr_requests grown

Allocate and free sched_tags while queue is freezed can deadlock[1],
this is a long term problem, hence allocate memory before freezing
queue and free memory after queue is unfreezed.

[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
References: https://git.kernel.org/stable/c/8d26acf8477174d8ef690eb6affe13a630f586ae; https://git.kernel.org/stable/c/b86433721f46d934940528f28d49c1dedb690df1
CVE: CVE-2025-40147
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-throttle: fix access race during throttle policy activation

On repeated cold boots we occasionally hit a NULL pointer crash in
blk_should_throtl() when throttling is consulted before the throttle
policy is fully enabled for the queue. Checking only q->td != NULL is
insufficient during early initialization, so blkg_to_pd() for the
throttle policy can still return NULL and blkg_to_tg() becomes NULL,
which later gets dereferenced.

 Unable to handle kernel NULL pointer dereference
 at virtual address [PII_REDACTED]
 ...
 pc : submit_bio_noacct+0x14c/0x4c8
 lr : submit_bio_noacct+0x48/0x4c8
 sp : ffff800087f0b690
 x29: ffff800087f0b690 x28:[PII_REDACTED]005f90 x27: ffff00068af393c0
 x26: [PII_REDACTED] x25:[PII_REDACTED]02fbc0 x24: ffff000684ddcc70
 x23: [PII_REDACTED] x22: [PII_REDACTED] x21: [PII_REDACTED]
 x20: [PII_REDACTED] x19: ffff000684ddcd08 x18: ffffffffffffffff
 x17: [PII_REDACTED] x16: ffff80008132a550 x15: 0000ffff98020fff
 x14: [PII_REDACTED] x13: 1fffe000d11d7021 x12: ffff000688eb810c
 x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60
 x8 : 00000a6fb8a86e85 x7 :[PII_REDACTED]00111e x6 : [PII_REDACTED]
 x5 : [PII_REDACTED] x4 :[PII_REDACTED]015cff x3 : [PII_REDACTED]
 x2 : ffff000682e35e40 x1 : [PII_REDACTED] x0 :[PII_REDACTED]00001a
 Call trace:
  submit_bio_noacct+0x14c/0x4c8
  verity_map+0x178/0x2c8
  __map_bio+0x228/0x250
  dm_submit_bio+0x1c4/0x678
  __submit_bio+0x170/0x230
  submit_bio_noacct_nocheck+0x16c/0x388
  submit_bio_noacct+0x16c/0x4c8
  submit_bio+0xb4/0x210
  f2fs_submit_read_bio+0x4c/0xf0
  f2fs_mpage_readpages+0x3b0/0x5f0
  f2fs_readahead+0x90/0xe8

Tighten blk_throtl_activated() to also require that the throttle policy
bit is set on the queue:

  return q->td != NULL &&
         test_bit(blkcg_policy_throtl.plid, q->blkcg_pols);

This prevents blk_should_throtl() from accessing throttle group state
until policy data has been attached to blkgs.
References: https://git.kernel.org/stable/c/6a0c394300a7b0c[PII_REDACTED]5de8a46707171fc; https://git.kernel.org/stable/c/7b4bfd02c934dbbb18814ed012ecb90b58db6935; https://git.kernel.org/stable/c/bd9fd5be6bc[PII_REDACTED]f68fff144609fbd85a9
CVE: CVE-2025-40148
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions

The function dc_stream_set_cursor_attributes() currently dereferences
the `stream` pointer and nested members `stream->ctx->dc->current_state`
without checking for NULL.

All callers of these functions, such as in
`dcn30_apply_idle_power_optimizations()` and
`amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks
before calling these functions.

Fixes below:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes()
error: we previously assumed 'stream' could be null (see line 334)

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c
    327 bool dc_stream_program_cursor_attributes(
    328         struct dc_stream_state *stream,
    329         const struct dc_cursor_attributes *attributes)
    330 {
    331         struct dc  *dc;
    332         bool reset_idle_optimizations = false;
    333
    334         dc = stream ? stream->ctx->dc : NULL;
                     ^^^^^^
The old code assumed stream could be NULL.

    335
--> 336         if (dc_stream_set_cursor_attributes(stream, attributes)) {
                                                    ^^^^^^
The refactor added an unchecked dereference.

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c
   313  bool dc_stream_set_cursor_attributes(
   314          struct dc_stream_state *stream,
   315          const struct dc_cursor_attributes *attributes)
   316  {
   317          bool result = false;
   318
   319          if (dc_stream_check_cursor_attributes(stream, stream->ctx->dc->current_state, attributes)) {
                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here.
This function used to check for if stream as NULL and return false at
the start. Probably we should add that back.
References: https://git.kernel.org/stable/c/01e793e7d4d402c473f1a61ca5824f086693be65; https://git.kernel.org/stable/c/bf4e4b97d0fdc66f04fc19d807e24dd8421b8f11
CVE: CVE-2025-40149
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().

get_netdev_for_sock() is called during setsockopt(),
so not under RCU.

Using sk_dst_get(sk)->dev could trigger UAF.

Let's use __sk_dst_get() and dst_dev_rcu().

Note that the only ->ndo_sk_get_lower_dev() user is
bond_sk_get_lower_dev(), which uses RCU.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/13159c[PII_REDACTED]543a82cb7bbae00ab36730cc; https://git.kernel.org/stable/c/2b1bef126bbb8d0da[PII_REDACTED]9126d567c1dee; https://git.kernel.org/stable/c/c65f27b9c3be2269918e1cbad6d8884741f835c5
CVE: CVE-2025-40150
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid migrating empty section

It reports a bug from device w/ zufs:

F2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT
F2FS-fs (dm-64): Stopped filesystem due to reason: 4

Thread A				Thread B
- f2fs_expand_inode_data
 - f2fs_allocate_pinning_section
  - f2fs_gc_range
   - do_garbage_collect w/ segno #x
					- writepage
					 - f2fs_allocate_data_block
					  - new_curseg
					   - allocate segno #x

The root cause is: fallocate on pinning file may race w/ block allocation
as above, result in do_garbage_collect() from fallocate() may migrate
segment which is just allocated by a log, the log will update segment type
in its in-memory structure, however GC will get segment type from on-disk
SSA block, once segment type changes by log, we can detect such
inconsistency, then shutdown filesystem.

In this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE),
however segno #173822 was just allocated as data type segment, so in-memory
SIT shows type of segno #173822 is 0 (SUM_TYPE_DATA).

Change as below to fix this issue:
- check whether current section is empty before gc
- add sanity checks on do_garbage_collect() to avoid any race case, result
in migrating segment used by log.
- btw, it fixes misc issue in printed logs: "SSA and SIT" -> "SIT and SSA".
References: https://git.kernel.org/stable/c/25d2dc669f2a7e48b335d1cb07139f2ffc9fe5df; https://git.kernel.org/stable/c/d625a2b08c089397d3a03bff13fa8645e4ec7a01; https://git.kernel.org/stable/c/db489778e6f2a4034c2cd26fadda2796eba24dcd
CVE: CVE-2025-40151
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: BPF: No support of struct argument in trampoline programs

The current implementation does not support struct argument. This causes
a oops when running bpf selftest:

  $ ./test_progs -a tracing_struct
  Oops[#1]:
  CPU -1 Unable to handle kernel paging request at virtual address [PII_REDACTED], era ==[PII_REDACTED]bef268, ra ==[PII_REDACTED]4f3938
  rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
  rcu:     1-...0: (19 ticks this GP) idle=1094/1/0x[PII_REDACTED]000000 softirq=1380/1382 fqs=801
  rcu:     (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)
  Sending NMI from CPU 0 to CPUs 1:
  rcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2
  rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
  rcu: RCU grace-period kthread stack dump:
  task:rcu_preempt     state:I stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000800
  Stack :[PII_REDACTED]423e80 [PII_REDACTED] [PII_REDACTED][PII_REDACTED]3b0680
         [PII_REDACTED]d88000 [PII_REDACTED] [PII_REDACTED] [PII_REDACTED]
         [PII_REDACTED]c2b9b0 [PII_REDACTED][PII_REDACTED]04a000 [PII_REDACTED]
          00000000ffff355b 00000000ffff355b [PII_REDACTED] [PII_REDACTED]
         [PII_REDACTED]d90510 [PII_REDACTED] [PII_REDACTED] 7b5d998f8281e86e
          00000000ffff355c 7b5d998f8281e86e[PII_REDACTED]00003f [PII_REDACTED]
         [PII_REDACTED]15bf98 [PII_REDACTED] [PII_REDACTED][PII_REDACTED]04a000
         [PII_REDACTED]407c98[PII_REDACTED]3aff80[PII_REDACTED]15c4c0[PII_REDACTED]c2b9b0
          00000000ffff355b[PII_REDACTED]c33d3c[PII_REDACTED]0000b4 [PII_REDACTED]
          [PII_REDACTED] 00000000ffff355b [PII_REDACTED] [PII_REDACTED]
          ...
  Call Trace:
  [<[PII_REDACTED]c2a868>] __schedule+0x410/0x1520
  [<[PII_REDACTED]c2b9ac>] schedule+0x34/0x190
  [<[PII_REDACTED]c33d38>] schedule_timeout+0x98/0x140
  [<[PII_REDACTED]5e9120>] rcu_gp_fqs_loop+0x5f8/0x868
  [<[PII_REDACTED]5ed538>] rcu_gp_kthread+0x260/0x2e0
  [<[PII_REDACTED]54e8a4>] kthread+0x144/0x238
  [<[PII_REDACTED]c26b60>] ret_from_kernel_thread+0x28/0xc8
  [<[PII_REDACTED]4f20e4>] ret_from_kernel_thread_asm+0xc/0x88

  rcu: Stack dump where RCU GP kthread last ran:
  Sending NMI from CPU 0 to CPUs 2:
  NMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4

Reject it for now.
References: https://git.kernel.org/stable/c/d[PII_REDACTED]43e11bfaabcd4b2bea98c7ed1be9; https://git.kernel.org/stable/c/e82406c7cbdd368c5459b8a45e118811d2ba0794
CVE: CVE-2025-40153
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: hugetlb: avoid soft lockup when mprotect to large memory area

When calling mprotect() to a large hugetlb memory area in our customer's
workload (~300GB hugetlb memory), soft lockup was observed:

watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]

CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7
Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mte_clear_page_tags+0x14/0x24
lr : mte_sync_tags+0x1c0/0x240
sp : ffff80003150bb80
x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000
x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: [PII_REDACTED]
x23: [PII_REDACTED] x22: [PII_REDACTED] x21: 000000011b380000
x20: ffff[PII_REDACTED]00 x19: 000000011b379f40 x18: [PII_REDACTED]
x17: [PII_REDACTED] x16: [PII_REDACTED] x15: [PII_REDACTED]
x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
x11: [PII_REDACTED] x10: [PII_REDACTED] x9 : ffffc875e0aa5e2c
x8 : [PII_REDACTED] x7 : [PII_REDACTED] x6 : [PII_REDACTED]
x5 : fffffc01ce7a5c00 x4 :[PII_REDACTED]6cde00 x3 : fffffc[PII_REDACTED]
x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffff0046cde7c000

Call trace:
  mte_clear_page_tags+0x14/0x24
  set_huge_pte_at+0x25c/0x280
  hugetlb_change_protection+0x220/0x430
  change_protection+0x5c/0x8c
  mprotect_fixup+0x10c/0x294
  do_mprotect_pkey.constprop.0+0x2e0/0x3d4
  __arm64_sys_mprotect+0x24/0x44
  invoke_syscall+0x50/0x160
  el0_svc_common+0x48/0x144
  do_el0_svc+0x30/0xe0
  el0_svc+0x30/0xf0
  el0t_64_sync_handler+0xc4/0x148
  el0t_64_sync+0x1a4/0x1a8

Soft lockup is not triggered with THP or base page because there is
cond_resched() called for each PMD size.

Although the soft lockup was triggered by MTE, it should be not MTE
specific.  The other processing which takes long time in the loop may
trigger soft lockup too.

So add cond_resched() for hugetlb to avoid soft lockup.
References: https://git.kernel.org/stable/c/30498c44c2a0b20f6833ed7d8fc3df901507f760; https://git.kernel.org/stable/c/4975c975ed9457a77953a26aeef85fdba7cf5498; https://git.kernel.org/stable/c/547e123e9d342a44c756446640ed847a8aeec611