huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslot
CVE: CVE-2025-68810
Component: kernel
Severity: None
Release date: 2025-01-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslot

Reject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that was
initially created with a guest_memfd binding, as KVM doesn't support
toggling KVM_MEM_GUEST_MEMFD on existing memslots.  KVM prevents enabling
KVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag.

Failure to reject the new memslot results in a use-after-free due to KVM
not unbinding from the guest_memfd instance.  Unbinding on a FLAGS_ONLY
change is easy enough, and can/will be done as a hardening measure (in
anticipation of KVM supporting dirty logging on guest_memfd at some point),
but fixing the use-after-free would only address the immediate symptom.

  ==================================================================
  BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm]
  Write of size 8 at addr ffff8881111ae908 by task repro/745

  CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  Call Trace:
   <TASK>
   dump_stack_lvl+0x51/0x60
   print_report+0xcb/0x5c0
   kasan_report+0xb4/0xe0
   kvm_gmem_release+0x362/0x400 [kvm]
   __fput+0x2fa/0x9d0
   task_work_run+0x12c/0x200
   do_exit+0x6ae/0x2100
   do_group_exit+0xa8/0x230
   __x64_sys_exit_group+0x3a/0x50
   x64_sys_call+0x737/0x740
   do_syscall_64+0x5b/0x900
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
  RIP: 0033:0x7f581f2eac31
   </TASK>

  Allocated by task 745 on cpu 6 at 9.746971s:
   kasan_save_stack+0x20/0x40
   kasan_save_track+0x13/0x50
   __kasan_kmalloc+0x77/0x90
   kvm_set_memory_region.part.0+0x652/0x1110 [kvm]
   kvm_vm_ioctl+0x14b0/0x3290 [kvm]
   __x64_sys_ioctl+0x129/0x1a0
   do_syscall_64+0x5b/0x900
   entry_SYSCALL_64_after_hwframe+0x4b/0x53

  Freed by task 745 on cpu 6 at 9.747467s:
   kasan_save_stack+0x20/0x40
   kasan_save_track+0x13/0x50
   __kasan_save_free_info+0x37/0x50
   __kasan_slab_free+0x3b/0x60
   kfree+0xf5/0x440
   kvm_set_memslot+0x3c2/0x1160 [kvm]
   kvm_set_memory_region.part.0+0x86a/0x1110 [kvm]
   kvm_vm_ioctl+0x14b0/0x3290 [kvm]
   __x64_sys_ioctl+0x129/0x1a0
   do_syscall_64+0x5b/0x900
   entry_SYSCALL_64_after_hwframe+0x4b/0x53


Remediation:
KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses
CVE: CVE-2025-23141
Component: kernel
CWE: CWE-284
Severity: Moderate
CVSS v3: 6.2/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L
Release date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses

Acquire a lock on kvm->srcu when userspace is getting MP state to handle a
rather extreme edge case where "accepting" APIC events, i.e. processing
pending INIT or SIPI, can trigger accesses to guest memory.  If the vCPU
is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP
state will trigger a nested VM-Exit by way of ->check_nested_events(), and
emuating the nested VM-Exit can access guest memory.

The splat was originally hit by syzkaller on a Google-internal kernel, and
reproduced on an upstream kernel by hacking the triple_fault_event_test
selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a
memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.

  =============================
  WARNING: suspicious RCU usage
  6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
  -----------------------------
  include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!

  other info that might help us debug this:

  rcu_scheduler_active = 2, debug_locks = 1
  1 lock held by triple_fault_ev/1256:
   #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]

  stack backtrace:
  CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  Call Trace:
   <TASK>
   dump_stack_lvl+0x7f/0x90
   lockdep_rcu_suspicious+0x144/0x190
   kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]
   kvm_vcpu_read_guest+0x3e/0x90 [kvm]
   read_and_check_msr_entry+0x2e/0x180 [kvm_intel]
   __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]
   kvm_check_nested_events+0x1b/0x30 [kvm]
   kvm_apic_accept_events+0x33/0x100 [kvm]
   kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]
   kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]
   __x64_sys_ioctl+0x8b/0xb0
   do_syscall_64+0x6c/0x170
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
   </TASK>

Statement: The security impact is limited by potentially accessing guest memory when KVM virtual machine being used.

Remediation:
To mitigate this issue, prevent module kvm from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
CVE: CVE-2025-2450
Component: NI Vision Builder AI VBAI File Processing Missing Warning Remote Code Execution Vulnerability
Release date: 2025-03-17T20:34:30.786000+00:00

NI Vision Builder AI VBAI File Processing Missing Warning Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of NI Vision Builder AI. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the processing of VBAI files. The issue results from allowing the execution of dangerous script without user warning. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-22833.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
Linux kernel: NULL pointer dereference in mount leads to local denial of service
CVE: CVE-2025-40195
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-11-12T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mount: handle NULL values in mnt_ns_release()

When calling in listmount() mnt_ns_release() may be passed a NULL
pointer. Handle that case gracefully.

Statement: The vulnerability is a NULL pointer dereference in pid_nr_ns() when it is called with a NULL PID namespace, leading to a kernel panic from paths such as __task_pid_nr_ns() on certain platforms. In realistic setups, this is a local denial-of-service issue, likely requiring specific kernel configuration or privileges to trigger reliably. In a worst-case scenario where unprivileged users can reach this path in a controlled way, any local user could crash the system.

Remediation:
Use after free in Storage
CVE: CVE-2025-11460
Component: chromium-browser
CVSS v3: 8.7/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Release date: 2025-11-06T22:26:49.566000+00:00

Use after free in Storage in Google Chrome prior to 141.0.7390.65 allowed a remote attacker to execute arbitrary code via a crafted video file. (Chromium security severity: High)

Statement: Red Hat Product Security rates the severity of this flaw as determined by the Google Chrome Security Advisory.

Remediation:
Authentication bypass in timestamp
CVE: CVE-2025-64517
Component: sudo-rs
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
Release date: 2025-11-12T22:08:29.422000+00:00

A flaw was found in sudo-rs. This vulnerability allows authentication bypass via incorrect recording of the authenticating user in the timestamp.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
vLLM Allows Remote Code Execution via PyNcclPipe Communication Service
CVE: CVE-2025-47277
Component: vllm
CWE: CWE-502
Severity: Moderate
CVSS v3: 7.5/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Release date: 2025-05-20T17:32:27.034000+00:00

A flaw was found in vLLM. This vulnerability allows unauthorized access to key-value caches via network exposure of the `TCPStore` interface when using the `PyNcclPipe` KV cache transfer integration with the V0 engine.

Statement: By default, Red Hat products are configured to restrict vLLM nodes to an isolated network. However, this vulnerability could become relevant if customers change the specific configurations, and therefore, Red Hat products are affected.

This vulnerability is classified as Moderate rather than Critical because its exploitability and impact are constrained by specific deployment contexts and assumptions about network trust boundaries. While the use of pickle.loads on untrusted input typically leads to remote code execution (RCE), the vulnerable PyNcclPipe interface is not intended to be exposed to the internet or untrusted networks, it is designed for use within a secured, internal cluster environment as explicitly documented by vLLM. Successful exploitation requires an attacker to have direct network access to a misconfigured or poorly segmented system where the KV cache transfer service is bound to a public interface. Additionally, the vulnerable code path exists only in a niche configuration (V0 engine with PyNcclPipe), further reducing its exposure. Therefore, while the flaw does introduce RCE risk in misconfigured setups, the combination of non-default exposure, clear documentation, and limited applicability justifies a reduced impact.

Remediation:
For more information visit https://access.redhat.com/errata/RHSA-2025:10404
For more information visit https://access.redhat.com/errata/RHSA-2025:10403
For more information visit https://access.redhat.com/errata/RHSA-2025:15839
For more information visit https://access.redhat.com/errata/RHSA-2025:15838
For more information visit https://access.redhat.com/errata/RHSA-2025:15840
For more information visit https://access.redhat.com/errata/RHSA-2025:15842
For more information visit https://access.redhat.com/errata/RHSA-2025:15837
For more information visit https://access.redhat.com/errata/RHSA-2025:15836
For more information visit https://access.redhat.com/errata/RHSA-2025:15841
For more information visit https://access.redhat.com/errata/RHSA-2025:15843
For more information visit https://access.redhat.com/errata/RHSA-2025:15867
For more information visit https://access.redhat.com/errata/RHSA-2025:15832
No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability.
bpf: Avoid __bpf_prog_ret0_warn when jit fails
CVE: CVE-2025-38280
Component: kernel
CWE: CWE-670
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-07-10T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

bpf: Avoid __bpf_prog_ret0_warn when jit fails

syzkaller reported an issue:

WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Modules linked in:
CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39
RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Call Trace:
 <TASK>
 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
 __bpf_prog_run include/linux/filter.h:718 [inline]
 bpf_prog_run include/linux/filter.h:725 [inline]
 cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105
 ...

When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.
This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set
and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,
but jit failed due to FAULT_INJECTION. As a result, incorrectly
treats the program as valid, when the program runs it calls
`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).

Statement: A flaw was found in the BPF JIT selection logic. When CONFIG_BPF_JIT_ALWAYS_ON is not set and bpf_jit_enable=1, the system may attempt to JIT-compile a BPF program. If JIT compilation fails (e.g., due to fault injection or unsupported architecture), the program may still be treated as valid. When later executed, this leads to invocation of __bpf_prog_ret0_warn() which triggers WARN_ON_ONCE(1) and kernel warning. This issue was reported by syzkaller and occurs due to incorrectly treating a non-JITed program as valid. For the Red Hat Enterprise Linux the BPF not accessible by default (and only root user can enable it).

Remediation:
uio_hv_generic: Let userspace take care of interrupt mask
CVE: CVE-2025-40048
Component: kernel
CWE: CWE-362
Severity: Moderate
CVSS v3: 6.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-10-28T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

uio_hv_generic: Let userspace take care of interrupt mask

Remove the logic to set interrupt mask by default in uio_hv_generic
driver as the interrupt mask value is supposed to be controlled
completely by the user space. If the mask bit gets changed
by the driver, concurrently with user mode operating on the ring,
the mask bit may be set when it is supposed to be clear, and the
user-mode driver will miss an interrupt which will cause a hang.

For eg- when the driver sets inbound ring buffer interrupt mask to 1,
the host does not interrupt the guest on the UIO VMBus channel.
However, setting the mask does not prevent the host from putting a
message in the inbound ring buffer. So let’s assume that happens,
the host puts a message into the ring buffer but does not interrupt.

Subsequently, the user space code in the guest sets the inbound ring
buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.
User space code then calls pread() to wait for an interrupt.
Then one of two things happens:

* The host never sends another message. So the pread() waits forever.
* The host does send another message. But because there’s already a
  message in the ring buffer, it doesn’t generate an interrupt.
  This is the correct behavior, because the host should only send an
  interrupt when the inbound ring buffer transitions from empty to
  not-empty. Adding an additional message to a ring buffer that is not
  empty is not supposed to generate an interrupt on the guest.
  Since the guest is waiting in pread() and not removing messages from
  the ring buffer, the pread() waits forever.

This could be easily reproduced in hv_fcopy_uio_daemon if we delay
setting interrupt mask to 0.

Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
there’s a race condition. Once user space empties the inbound ring
buffer, but before user space sets interrupt_mask to 0, the host could
put another message in the ring buffer but it wouldn’t interrupt.
Then the next pread() would hang.

Fix these by removing all instances where interrupt_mask is changed,
while keeping the one in set_event() unchanged to enable userspace
control the interrupt mask by writing 0/1 to /dev/uioX.

Statement: The uio_hv_generic driver raced userspace by unilaterally toggling the ring’s interrupt_mask. If the kernel set the mask while userspace was operating on the ring, an inbound message could arrive without an interrupt, and subsequent pread() would block indefinitely since no “empty→non-empty” transition occurs.
This affects the guest only and can be triggered only by a local user with access to the guest’s UIO channel (e.g. /dev/uioX) — access which is not granted to ordinary users by default.

Remediation:
CVE: CVE-2025-7275
Component: IrfanView CADImage Plugin CGM File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability
Release date: 2025-07-08T19:58:08.731000+00:00

IrfanView CADImage Plugin CGM File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of IrfanView CADImage Plugin. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of CGM files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26204.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
thermal: int340x: Add NULL check for adev
CVE: CVE-2025-23136
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL.
This is similar to the commit cd2fd6eab480
("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in int3402_thermal_probe().

Note, under the same directory, int3400_thermal_probe() has such a
check.

[ rjw: Subject edit, added Fixes: ]


Remediation:
net: xdp: Disallow attaching device-bound programs in generic mode
CVE: CVE-2025-21808
Component: kernel
CWE: CWE-703
Severity: Moderate
CVSS v3: 4.4/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: xdp: Disallow attaching device-bound programs in generic mode

Device-bound programs are used to support RX metadata kfuncs. These
kfuncs are driver-specific and rely on the driver context to read the
metadata. This means they can't work in generic XDP mode. However, there
is no check to disallow such programs from being attached in generic
mode, in which case the metadata kfuncs will be called in an invalid
context, leading to crashes.

Fix this by adding a check to disallow attaching device-bound programs
in generic mode.


Remediation:
Avahi: Denial of Service via unsolicited CNAME announcements
CVE: CVE-2025-68471
Component: avahi
CWE: CWE-617
Severity: Moderate
CVSS v3: 6.4/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Release date: 2025-01-01T00:00:00+00:00

A flaw was found in Avahi, a system that enables devices to discover services on a local network using the mDNS/DNS-SD (Multicast Domain Name System/DNS-based Service Discovery) protocols. A remote attacker can exploit this by sending two specific network messages, known as unsolicited announcements with CNAME resource records, within a two-second timeframe. This action can cause the `avahi-daemon` process to crash, leading to a Denial of Service (DoS) for the affected system.


Remediation:
Spring Cloud Config Server May Not Use Vault Token Sent By Clients
CVE: CVE-2025-22232
Component: spring-cloud-config-server
CWE: CWE-287
Severity: Moderate
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Release date: 2025-04-10T17:26:56.755000+00:00

Spring Cloud Config Server may not use Vault token sent by clients using a X-CONFIG-TOKEN header when making requests to Vault.
Your application may be affected by this if the following are true:
  *  You have Spring Vault on the classpath of your Spring Cloud Config Server and
  *  You are using the X-CONFIG-TOKEN header to send a Vault token to the Spring Cloud Config Server for the Config Server to use when making requests to Vault and
  *  You are using the default Spring Vault SessionManager implementation LifecycleAwareSessionManager or a SessionManager implementation that persists the Vault token such as SimpleSessionManager.

In this case the SessionManager persists the first token it retrieves and will continue to use that token even if client requests to the Spring Cloud Config Server include a X-CONFIG-TOKEN header with a different value.
Affected Spring Products and Versions
Spring Cloud Config:
  *  2.2.1.RELEASE - 4.2.1


Mitigation
Users of affected versions should upgrade to the corresponding fixed version.

Affected version(s)Fix versionAvailability4.2.x4.2.2OSS4.1.x4.1.6OSS4.0.x4.0.10Commercial3.1.x3.1.10Commercial3.0.x4.1.6OSS2.2.x4.1.6OSS
NOTE: Spring Cloud Config 3.0.x and 2.2.x are no longer under open source or commercial support. Users of these versions are encouraged to upgrade to a supported version.

No other mitigation steps are necessary.


Remediation:
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
octeon_ep: Fix host hang issue during device reboot
CVE: CVE-2025-37933
Component: kernel
CWE: CWE-1341
Severity: Moderate
CVSS v3: 5.6/AV:P/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
Release date: 2025-05-20T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: Fix host hang issue during device reboot

When the host loses heartbeat messages from the device,
the driver calls the device-specific ndo_stop function,
which frees the resources. If the driver is unloaded in
this scenario, it calls ndo_stop again, attempting to free
resources that have already been freed, leading to a host
hang issue. To resolve this, dev_close should be called
instead of the device-specific stop function.dev_close
internally calls ndo_stop to stop the network interface
and performs additional cleanup tasks. During the driver
unload process, if the device is already down, ndo_stop
is not called.


Remediation:
ksmbd: fix use-after-free in session logoff
CVE: CVE-2025-37899
Component: kernel
CWE: CWE-416
Severity: Low
CVSS v3: 4.7/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-05-20T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in session logoff

The sess->user object can currently be in use by another thread, for
example if another connection has sent a session setup request to
bind to the session being free'd. The handler for that connection could
be in the smb2_sess_setup function which makes use of sess->user.


Remediation:
mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode
CVE: CVE-2025-71200
Component: kernel
Severity: None
Release date: 2025-01-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode

When operating in HS200 or HS400 timing modes, reducing the clock frequency
below 52MHz will lead to link broken as the Rockchip DWC MSHC controller
requires maintaining a minimum clock of 52MHz in these modes.

Add a check to prevent illegal clock reduction through debugfs:

root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock
root@debian:/# [   30.090146] mmc0: running CQE recovery
mmc0: cqhci: Failed to halt
mmc0: cqhci: spurious TCN for tag 0
WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24
Modules linked in:
CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT
Hardware name: Rockchip RK3588 EVB1 V10 Board (DT)
Workqueue: kblockd blk_mq_run_work_fn
pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : cqhci_irq+0x254/0x818
lr : cqhci_irq+0x254/0x818
...


Remediation: