medium CVSS 5.5

CVE-2025-21876·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix suspicious RCU usage Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts locally") moved the call to enable_drhd_fault_handling() to a code path that does not hold any lock while traversing the drhd list. Fix it by ensuring the dmar_global_lock lock is held when traversing the drhd list. Without this fix, the following warning is triggered: ============================= WARNING: suspicious RCU usage 6.14.0-rc3 #55 Not tainted ----------------------------- drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by cpuhp/1/23: #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55 Call Trace: <TASK> dump_stack_lvl+0xb7/0xd0 lockdep_rcu_suspicious+0x159/0x1f0 ? __pfx_enable_drhd_fault_handling+0x10/0x10 enable_drhd_fault_handling+0x151/0x180 cpuhp_invoke_callback+0x1df/0x990 cpuhp_thread_fun+0x1ea/0x2c0 smpboot_thread_fn+0x1f5/0x2e0 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x12a/0x2d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4a/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat about a possible deadlock between dmar_global_lock and cpu_hotplug_lock. This is avoided by not holding dmar_global_lock when calling iommu_device_register(), which initiates the device probe process.

Severity
medium
Software
Kernel
Fixed in
6.13.6
Published
2025-03-27

Affected versions

From: 6.13

Until: 6.13.6

Fixed in: 6.13.6

How to fix this CVE

Update your Linux kernel to version 6.13.6 or later to resolve a synchronization issue in the Intel IOMMU driver's fault handling initialization. This patch ensures proper locking during device enumeration on multi-core systems and prevents kernel warnings and potential stability issues during CPU hotplug operations.

sudo dnf update kernel kernel-devel

Defensia detects this vulnerability

How to check if you are affected

  1. Check your kernel version: uname -r — confirm if it is between 6.13 and 6.13.6
  2. Verify IOMMU presence: grep -i iommu /proc/cmdline — check if Intel DMAR (VT-d) is enabled in your boot parameters
  3. Review kernel logs for RCU warnings: sudo dmesg | grep -A 5 'suspicious RCU usage' — look for warnings referencing drivers/iommu/intel/dmar.c:2046
  4. Confirm patch status: grep -i vt-d /proc/version — if kernel is ≥6.13.6, the fix is applied

FAQ

What is CVE-2025-21876?

This vulnerability is a synchronization bug in the Linux kernel's Intel IOMMU (VT-d) driver where a critical list traversal was performed without proper locking, causing RCU (Read-Copy-Update) warnings and potential race conditions during CPU hotplug events.

Is CVE-2025-21876 being actively exploited?

No, this vulnerability is not being actively exploited in the wild. There are no public exploits available, and it is not tracked by CISA's Known Exploited Vulnerabilities (KEV) catalog.

What versions of Kernel are affected by CVE-2025-21876?

Linux kernel versions 6.13 through 6.13.5 are affected. The vulnerability was introduced in kernel 6.13 and patched in version 6.13.6.

How do I check if my server is vulnerable to CVE-2025-21876?

Run 'uname -r' to check your kernel version. If the output shows a version between 6.13 and 6.13.5 (e.g., 6.13.0, 6.13.3, 6.13.5), your system is vulnerable. Also verify VT-d is enabled with 'grep iommu /proc/cmdline'.

Does Defensia detect CVE-2025-21876?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If the Linux kernel is installed on a monitored server, CVE-2025-21876 will appear in your dashboard with remediation steps.

Related Kernel CVEs

CVE-2026-100075CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error.
CVE-2026-64387CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix query directory replay double-free A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_query_directory_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free.
CVE-2026-53176CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.
CVE-2026-64399CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE The FSCTL_DUPLICATE_EXTENTS_TO_FILE arm of smb2_ioctl() overwrites the destination file's data via vfs_clone_file_range() with neither the share-level KSMBD_TREE_CONN_FLAG_WRITABLE check nor a per-handle fp->daccess check that the other write-bearing arms carry. A client can overwrite destination data on a read-only share, or from a handle opened with only FILE_WRITE_ATTRIBUTES (which still yields an FMODE_WRITE filp). FILE_WRITE_ATTRIBUTES-only destination handle overwrote the file's data via the clone. Add both checks, matching the FSCTL_SET_SPARSE permission fix; require FILE_WRITE_DATA since this writes data.
CVE-2026-64385CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_ioctl() replay A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_ioctl_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2025-21876. Free for 1 server.

Get started free