deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38506
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: Allow CPU to reschedule while setting per-page memory attributes

When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),
the host can experience CPU soft lockups when running an operation in
kvm_vm_set_mem_attributes() to set memory attributes on the whole
range of guest memory.

watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]
CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)
Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024
RIP: 0010:xas_create+0x78/0x1f0
Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87
RSP: 0018:ffffad890a34b940 EFLAGS: 00000286
RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: [PII_REDACTED]
RDX:[PII_REDACTED]00001e RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffffad890a356868
R13: ffffad890a356860 R14: [PII_REDACTED] R15: ffffad890a356868
FS:  00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f015c70fb18 CR3:[PII_REDACTED]9fd006 CR4:[PII_REDACTED]f70ef0
PKRU: 55555554
Call Trace:
 <TASK>
 xas_store+0x58/0x630
 __xa_store+0xa5/0x130
 xa_store+0x2c/0x50
 kvm_vm_set_mem_attributes+0x343/0x710 [kvm]
 kvm_vm_ioctl+0x796/0xab0 [kvm]
 __x64_sys_ioctl+0xa3/0xd0
 do_syscall_64+0x8c/0x7a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f5578d031bb
Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48
RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
RAX: ffffffffffffffda RBX:[PII_REDACTED]20aed2 RCX: 00007f5578d031bb
RDX: 00007ffe0a742c80 RSI:[PII_REDACTED]20aed2 RDI:[PII_REDACTED]00000b
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: 00005575e5f95120
R13: 00007ffe0a742c80 R14: [PII_REDACTED] R15: 00005575e5f961e0

While looping through the range of memory setting the attributes,
call cond_resched() to give the scheduler a chance to run a higher
priority task on the runqueue if necessary and avoid staying in
kernel mode long enough to trigger the lockup.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1ef45ae7a3938f0844032ba670b4f89180a5bffc; https://git.kernel.org/stable/c/47bb584237cc285e3a860b70c01f7bda9dcfb05b; https://git.kernel.org/stable/c/d9bd1163c8d8f716f45e54d034ee28757cc85549
CVE: CVE-2025-38507
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: nintendo: avoid bluetooth suspend/resume stalls

Ensure we don't stall or panic the kernel when using bluetooth-connected
controllers. This was reported as an issue on android devices using
kernel 6.6 due to the resume hook which had been added for usb joycons.

First, set a new state value to JOYCON_CTLR_STATE_SUSPENDED in a
newly-added nintendo_hid_suspend. This makes sure we will not stall out
the kernel waiting for input reports during led classdev suspend. The
stalls could happen if connectivity is unreliable or lost to the
controller prior to suspend.

Second, since we lose connectivity during suspend, do not try
joycon_init() for bluetooth controllers in the nintendo_hid_resume path.

Tested via multiple suspend/resume flows when using the controller both
in USB and bluetooth modes.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4a[PII_REDACTED]e77792a5168069f174d3e56175ff; https://git.kernel.org/stable/c/72cb7eef06a5cde42b324dea85fa11fd5bb6a08a; https://git.kernel.org/stable/c/7b4a026313529a487821ef6ab494a61f12c1db08
CVE: CVE-2025-38508
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/sev: Use TSC_FACTOR for Secure TSC frequency calculation

When using Secure TSC, the GUEST_TSC_FREQ MSR reports a frequency based on
the nominal P0 frequency, which deviates slightly (typically ~0.2%) from
the actual mean TSC frequency due to clocking parameters.

Over extended VM uptime, this discrepancy accumulates, causing clock skew
between the hypervisor and a SEV-SNP VM, leading to early timer interrupts as
perceived by the guest.

The guest kernel relies on the reported nominal frequency for TSC-based
timekeeping, while the actual frequency set during SNP_LAUNCH_START may
differ. This mismatch results in inaccurate time calculations, causing the
guest to perceive hrtimers as firing earlier than expected.

Utilize the TSC_FACTOR from the SEV firmware's secrets page (see "Secrets
Page Format" in the SNP Firmware ABI Specification) to calculate the mean
TSC frequency, ensuring accurate timekeeping and mitigating clock skew in
SEV-SNP VMs.

Use early_ioremap_encrypted() to map the secrets page as
ioremap_encrypted() uses kmalloc() which is not available during early TSC
initialization and causes a panic.

  [ bp: Drop the silly dummy var:
    https://lore.kernel.org/r/[PII_REDACTED]2726.GBaGLlHl84xIopx4Pt@fat_crate.local ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/52e1a03e6cf61ae165f59f41c44394a653a0a788; https://git.kernel.org/stable/c/d0195c42e65805938c9eb507657e7cdf8e1e9522
CVE: CVE-2025-38509
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: reject VHT opmode for unsupported channel widths

VHT operating mode notifications are not defined for channel widths
below 20 MHz. In particular, 5 MHz and 10 MHz are not valid under the
VHT specification and must be rejected.

Without this check, malformed notifications using these widths may
reach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due to
invalid input. This issue was reported by syzbot.

Reject these unsupported widths early in sta_link_apply_parameters()
when opmode_notif is used. The accepted set includes 20, 40, 80, 160,
and 80+80 MHz, which are valid for VHT. While 320 MHz is not defined
for VHT, it is allowed to avoid rejecting HE or EHT clients that may
still send a VHT opmode notification.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/18eca59a04500b68a90e0c5c873f97c9d1ea2bfa; https://git.kernel.org/stable/c/58fcb1b4287ce38850402bb2bb16d09bf77b91d9
CVE: CVE-2025-38510
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

kasan: remove kasan_find_vm_area() to prevent possible deadlock

find_vm_area() couldn't be called in atomic_context.  If find_vm_area() is
called to reports vm area information, kasan can trigger deadlock like:

CPU0                                CPU1
vmalloc();
 alloc_vmap_area();
  spin_lock(&vn->busy.lock)
                                    spin_lock_bh(&some_lock);
   <interrupt occurs>
   <in softirq>
   spin_lock(&some_lock);
                                    <access invalid address>
                                    kasan_report();
                                     print_report();
                                      print_address_description();
                                       kasan_find_vm_area();
                                        find_vm_area();
                                         spin_lock(&vn->busy.lock) // deadlock!

To prevent possible deadlock while kasan reports, remove kasan_find_vm_area().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0c3566d831def922cd56322c772a7b20d8b0e0c0; https://git.kernel.org/stable/c/2d89dab1ea6086e6cbe6fe92531b496fb6808cb9; https://git.kernel.org/stable/c/595f78d99b[PII_REDACTED]c0a5c4c47e1097e6ed01
CVE: CVE-2025-38511
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/pf: Clear all LMTT pages on alloc

Our LMEM buffer objects are not cleared by default on alloc
and during VF provisioning we only setup LMTT PTEs for the
actually provisioned LMEM range. But beyond that valid range
we might leave some stale data that could either point to some
other VFs allocations or even to the PF pages.

Explicitly clear all new LMTT page to avoid the risk that a
malicious VF would try to exploit that gap.

While around add asserts to catch any undesired PTE overwrites
and low-level debug traces to track LMTT PT life-cycle.

(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5d21892c2e15b6a27f8bc907693eca7c6b7cc269; https://git.kernel.org/stable/c/705a412a367f383430fa34bada387af2e52eb043; https://git.kernel.org/stable/c/ff4b8c9ade1b82979fdd01e6f45b60f92eed26d8
CVE: CVE-2025-38512
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: prevent A-MSDU attacks in mesh networks

This patch is a mitigation to prevent the A-MSDU spoofing vulnerability
for mesh networks. The initial update to the IEEE 802.11 standard, in
response to the FragAttacks, missed this case (CVE-2025-27558). It can
be considered a variant of CVE-2020-24588 but for mesh networks.

This patch tries to detect if a standard MSDU was turned into an A-MSDU
by an adversary. This is done by parsing a received A-MSDU as a standard
MSDU, calculating the length of the Mesh Control header, and seeing if
the 6 bytes after this header equal the start of an rfc1042 header. If
equal, this is a strong indication of an ongoing attack attempt.

This defense was tested with mac80211_hwsim against a mesh network that
uses an empty Mesh Address Extension field, i.e., when four addresses
are used, and when using a 12-byte Mesh Address Extension field, i.e.,
when six addresses are used. Functionality of normal MSDUs and A-MSDUs
was also tested, and confirmed working, when using both an empty and
12-byte Mesh Address Extension field.

It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh
networks keep being detected and prevented.

Note that the vulnerability being patched, and the defense being
implemented, was also discussed in the following paper and in the
following IEEE 802.11 presentation:

https://papers.mathyvanhoef.com/wisec2025.pdf
https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/6e3b09402cc6c3e3474fa548e8adf6897dda05de; https://git.kernel.org/stable/c/737bb912ebbe4571195c56eba557c4d7315b26fb; https://git.kernel.org/stable/c/e01851f6e9a665a6011b14714b271d3e6b0b8d32
CVE: CVE-2025-38513
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()

There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For
example, the following is possible:

    	T0			    		T1
zd_mac_tx_to_dev()
  /* len == skb_queue_len(q) */
  while (len > ZD_MAC_MAX_ACK_WAITERS) {

					  filter_ack()
					    spin_lock_irqsave(&q->lock, flags);
					    /* position == skb_queue_len(q) */
					    for (i=1; i<position; i++)
				    	      skb = __skb_dequeue(q)

					    if (mac->type == NL80211_IFTYPE_AP)
					      skb = __skb_dequeue(q);
					    spin_unlock_irqrestore(&q->lock, flags);

    skb_dequeue() -> NULL

Since there is a small gap between checking skb queue length and skb being
unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.
Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.

In order to avoid potential NULL pointer dereference due to situations like
above, check if skb is not NULL before passing it to zd_mac_tx_status().

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/014c34dc132015c4f918ada4982e952947ac1047; https://git.kernel.org/stable/c/5420de65efbeb6503bcf1d43451c9df67ad60298; https://git.kernel.org/stable/c/602b4eb2f25668de15de69860ec99caf65b3684d
CVE: CVE-2025-38514
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix oops due to non-existence of prealloc backlog struct

If an AF_RXRPC service socket is opened and bound, but calls are
preallocated, then rxrpc_alloc_incoming_call() will oops because the
rxrpc_backlog struct doesn't get allocated until the first preallocation is
made.

Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no
backlog struct.  This will cause the incoming call to be aborted.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0eef29385d715d4c7fd707b18d4a9b76c76dd5e6; https://git.kernel.org/stable/c/2c2e9ebeb036f9b1b09325ec5cfdfe0e78f357c3; https://git.kernel.org/stable/c/880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4
CVE: CVE-2025-38515
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/sched: Increment job count before swapping tail spsc queue

A small race exists between spsc_queue_push and the run-job worker, in
which spsc_queue_push may return not-first while the run-job worker has
already idled due to the job count being zero. If this race occurs, job
scheduling stops, leading to hangs while waiting on the job’s DMA
fences.

Seal this race by incrementing the job count before appending to the
SPSC queue.

This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in
an SVM test case.
CVSS Score: 4.7 (MEDIUM)
References: https://git.kernel.org/stable/c/549a9c78c3ea6807d0dc4162a4f5ba59f217d5a0; https://git.kernel.org/stable/c/8af39ec5cf2be522c8eb43a3d8005ed59e4daaee; https://git.kernel.org/stable/c/c64f5310530baf75328292f9b9f3f2961d185183
CVE: CVE-2025-38516
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: qcom: msm: mark certain pins as invalid for interrupts

On some platforms, the UFS-reset pin has no interrupt logic in TLMM but
is nevertheless registered as a GPIO in the kernel. This enables the
user-space to trigger a BUG() in the pinctrl-msm driver by running, for
example: `gpiomon -c 0 113` on RB2.

The exact culprit is requesting pins whose intr_detection_width setting
is not 1 or 2 for interrupts. This hits a BUG() in
msm_gpio_irq_set_type(). Potentially crashing the kernel due to an
invalid request from user-space is not optimal, so let's go through the
pins and mark those that would fail the check as invalid for the irq chip
as we should not even register them as available irqs.

This function can be extended if we determine that there are more
corner-cases like this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1d57f7132662e96aace3b8a000616efde289aae1; https://git.kernel.org/stable/c/275605a8b48002fe98675a5c06f3e39c09067ff2; https://git.kernel.org/stable/c/3f8fc02c2582c1dfad1785e9c7bc8b4e1521af0a
CVE: CVE-2025-38518
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/CPU/AMD: Disable INVLPGB on Zen2

AMD Cyan Skillfish (Family 17h, Model 47h, Stepping 0h) has an issue
that causes system oopses and panics when performing TLB flush using
INVLPGB.

However, the problem is that that machine has misconfigured CPUID and
should not report the INVLPGB bit in the first place. So zap the
kernel's representation of the flag so that nothing gets confused.

  [ bp: Massage. ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/357f121517924e3ec3021f9d0dd0189adcd09867; https://git.kernel.org/stable/c/a74bb5f202dabddfea96abc1328fcedae8aa140a
CVE: CVE-2025-38519
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon: fix divide by zero in damon_get_intervals_score()

The current implementation allows having zero size regions with no special
reasons, but damon_get_intervals_score() gets crashed by divide by zero
when the region size is zero.

  [   29.403950] Oops: divide error: 0000 [#1] SMP NOPTI

This patch fixes the bug, but does not disallow zero size regions to keep
the backward compatibility since disallowing zero size regions might be a
breaking change for some users.

In addition, the same crash can happen when intervals_goal.access_bp is
zero so this should be fixed in stable trees as well.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/bd225b[PII_REDACTED]beb876da72656f4a2d627d03; https://git.kernel.org/stable/c/ca4bb9ac706f05ead8ac1cce7b8245fc0645a687
CVE: CVE-2025-38520
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Don't call mmput from MMU notifier callback

If the process is exiting, the mmput inside mmu notifier callback from
compactd or fork or numa balancing could release the last reference
of mm struct to call exit_mmap and free_pgtable, this triggers deadlock
with below backtrace.

The deadlock will leak kfd process as mmu notifier release is not called
and cause VRAM leaking.

The fix is to take mm reference mmget_non_zero when adding prange to the
deferred list to pair with mmput in deferred list work.

If prange split and add into pchild list, the pchild work_item.mm is not
used, so remove the mm parameter from svm_range_unmap_split and
svm_range_add_child.

The backtrace of hung task:

 INFO: task python:348105 blocked for more than 64512 seconds.
 Call Trace:
  __schedule+0x1c3/0x550
  schedule+0x46/0xb0
  rwsem_down_write_slowpath+0x24b/0x4c0
  unlink_anon_vmas+0xb1/0x1c0
  free_pgtables+0xa9/0x130
  exit_mmap+0xbc/0x1a0
  mmput+0x5a/0x140
  svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]
  mn_itree_invalidate+0x72/0xc0
  __mmu_notifier_invalidate_range_start+0x48/0x60
  try_to_unmap_one+0x10fa/0x1400
  rmap_walk_anon+0x196/0x460
  try_to_unmap+0xbb/0x210
  migrate_page_unmap+0x54d/0x7e0
  migrate_pages_batch+0x1c3/0xae0
  migrate_pages_sync+0x98/0x240
  migrate_pages+0x25c/0x520
  compact_zone+0x29d/0x590
  compact_zone_order+0xb6/0xf0
  try_to_compact_pages+0xbe/0x220
  __alloc_pages_direct_compact+0x96/0x1a0
  __alloc_pages_slowpath+0x410/0x930
  __alloc_pages_nodemask+0x3a9/0x3e0
  do_huge_pmd_anonymous_page+0xd7/0x3e0
  __handle_mm_fault+0x5e3/0x5f0
  handle_mm_fault+0xf7/0x2e0
  hmm_vma_fault.isra.0+0x4d/0xa0
  walk_pmd_range.isra.0+0xa8/0x310
  walk_pud_range+0x167/0x240
  walk_pgd_range+0x55/0x100
  __walk_page_range+0x87/0x90
  walk_page_range+0xf6/0x160
  hmm_range_fault+0x4f/0x90
  amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]
  amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]
  init_user_pages+0xb1/0x2a0 [amdgpu]
  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]
  kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]
  kfd_ioctl+0x29d/0x500 [amdgpu]

(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/145a56bd68f4bff098d59fbc7c263d20dfef4fc4; https://git.kernel.org/stable/c/a7eb0a25010a674c8fdfbece38353ef7be8c5834; https://git.kernel.org/stable/c/c1bde9d48e09933c361521720f77a8072083c83a
CVE: CVE-2025-38521
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/imagination: Fix kernel crash when hard resetting the GPU

The GPU hard reset sequence calls pm_runtime_force_suspend() and
pm_runtime_force_resume(), which according to their documentation should
only be used during system-wide PM transitions to sleep states.

The main issue though is that depending on some internal runtime PM
state as seen by pm_runtime_force_suspend() (whether the usage count is
<= 1), pm_runtime_force_resume() might not resume the device unless
needed. If that happens, the runtime PM resume callback
pvr_power_device_resume() is not called, the GPU clocks are not
re-enabled, and the kernel crashes on the next attempt to access GPU
registers as part of the power-on sequence.

Replace calls to pm_runtime_force_suspend() and
pm_runtime_force_resume() with direct calls to the driver's runtime PM
callbacks, pvr_power_device_suspend() and pvr_power_device_resume(),
to ensure clocks are re-enabled and avoid the kernel crash.
CVSS Score: 7.1 (HIGH)
CWE: CWE-668
References: https://git.kernel.org/stable/c/9f852d301f642223c4798f3c13ba15e91165d078; https://git.kernel.org/stable/c/d38376b3ee48d073c64e75e150510d7e6b4b04f7; https://git.kernel.org/stable/c/e066cc6e0f094ca2120f1928d126d56f686cd73e
CVE: CVE-2025-9092
Published: 2025-08-16
Description: Uncontrolled Resource Consumption vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java - BC-FJA 2.1.0 bc-fips (API modules) allows Excessive Allocation. This vulnerability is associated with program files org.Bouncycastle.Crypto.Fips.NativeLoader.

This issue affects Bouncy Castle for Java - BC-FJA 2.1.0: from BC-FJA 2.1.0 through 2.1.0.
CWE: CWE-400
References: https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%909092
CVE: CVE-2025-38522
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/ext: Prevent update_locked_rq() calls with NULL rq

Avoid invoking update_locked_rq() when the runqueue (rq) pointer is NULL
in the SCX_CALL_OP and SCX_CALL_OP_RET macros.

Previously, calling update_locked_rq(NULL) with preemption enabled could
trigger the following warning:

    BUG: using __this_cpu_write() in preemptible [00000000]

This happens because __this_cpu_write() is unsafe to use in preemptible
context.

rq is NULL when an ops invoked from an unlocked context. In such cases, we
don't need to store any rq, since the value should already be NULL
(unlocked). Ensure that update_locked_rq() is only called when rq is
non-NULL, preventing calling __this_cpu_write() on preemptible context.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/237c43037b336e36a49eb9f2daac1c7719ec7f8b; https://git.kernel.org/stable/c/e14fd98c6d66cb76694b12c05768e4f9e8c95664
CVE: CVE-2025-38523
Published: 2025-08-16
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix the smbd_response slab to allow usercopy

The handling of received data in the smbdirect client code involves using
copy_to_iter() to copy data from the smbd_reponse struct's packet trailer
to a folioq buffer provided by netfslib that encapsulates a chunk of
pagecache.

If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks
then performed in copy_to_iter() oopsing with something like the following:

 CIFS: Attempting to mount //172.31.9.1/test
 CIFS: VFS: RDMA transport established
 usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_[PII_REDACTED]e24ea1' (offset 81, size 63)!
 ------------[ cut here ]------------
 kernel BUG at mm/usercopy.c:102!
 ...
 RIP: 0010:usercopy_abort+0x6c/0x80
 ...
 Call Trace:
  <TASK>
  __check_heap_object+0xe3/0x120
  __check_object_size+0x4dc/0x6d0
  smbd_recv+0x77f/0xfe0 [cifs]
  cifs_readv_from_socket+0x276/0x8f0 [cifs]
  cifs_read_from_socket+0xcd/0x120 [cifs]
  cifs_demultiplex_thread+0x7e9/0x2d50 [cifs]
  kthread+0x396/0x830
  ret_from_fork+0x2b8/0x3b0
  ret_from_fork_asm+0x1a/0x30

The problem is that the smbd_response slab's packet field isn't marked as
being permitted for usercopy.

Fix this by passing parameters to kmem_slab_create() to indicate that
copy_to_iter() is permitted from the packet region of the smbd_response
slab objects, less the header space.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-1188
References: https://git.kernel.org/stable/c/43e7e284fc77b710d899569360ea46fa3374ae22; https://git.kernel.org/stable/c/87dcc7e33fc3dcb8ed32333cec016528b5bb6ce4; https://git.kernel.org/stable/c/f0dd353d47f7051afa98c6c60c7486831eb1a410