CVE-2026-64232: Linux Kernel Privilege Escalation Flaw

CVE-2026-64232 Overview

CVE-2026-64232 is a Linux kernel vulnerability in the block layer's blk_insert_cloned_request() function. The flaw affects stacked block device drivers that carry integrity metadata across queues with differing segment limits. The kernel recomputes nr_phys_segments against the bottom queue but fails to recompute nr_integrity_segments, causing a mismatch between the cached count and the actual segment count produced by blk_rq_count_integrity_sg(). When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips a BUG_ON(segments > rq->nr_integrity_segments) on dispatch. Stacked configurations such as dm-multipath fanning out to nvme-rdma can trigger this condition during normal I/O.

Critical Impact
The kernel triggers a BUG_ON during I/O dispatch on stacked block devices carrying integrity metadata, resulting in kernel panic and system unavailability.

Affected Products

Linux kernel block layer (block/blk-mq.c)
Stacked block driver configurations including dm-multipath over nvme-rdma
Systems using T10 Protection Information (PI) or Data Integrity Field (DIF) with stacked queues

Discovery Timeline

2026-07-24 - CVE-2026-64232 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64232

Vulnerability Analysis

The Linux block layer supports stacked drivers where a top-level queue submits cloned requests to a bottom queue with potentially different segment constraints. The function blk_insert_cloned_request() accounts for this by recomputing nr_phys_segments against the bottom queue's virt_boundary_mask, seg_boundary_mask, and max_segment_size. The vulnerability stems from the same recomputation not being applied to integrity segments, even though the underlying queue can enforce tighter limits.

When a request carries integrity metadata, blk_rq_prep_clone() copies rq->nr_integrity_segments from the source request. If the bottom queue produces a higher segment count than the cached value, the dispatch path hits an unrecoverable BUG_ON in blk_rq_map_integrity_sg(). This crashes the kernel and terminates I/O processing on the affected node.

Root Cause

The root cause is an incomplete stacking contract in the block multi-queue subsystem. The function blk_insert_cloned_request() recomputes physical segment counts but does not invoke blk_rq_count_integrity_sg() against the bottom queue or validate the result against queue_max_integrity_segments(). The cached nr_integrity_segments inherited from the source queue becomes stale when the bottom queue applies stricter segment splitting rules.

Attack Vector

The crash triggers during legitimate I/O submission on stacked block devices with data integrity enabled. An attacker or unprivileged local workload issuing I/O to a dm-multipath device backed by nvme-rdma with mismatched queue limits can induce the BUG_ON. The reported CVSS vector indicates network reachability, consistent with remote I/O paths such as NVMe over RDMA fabrics feeding the affected stack. Successful triggering results in kernel panic and denial of service on the host handling the request.

No public proof-of-concept code has been published. The vulnerability manifests through normal block I/O dispatch rather than a crafted exploit payload. Refer to the upstream commits 0943f81e, 2c6e6a18, 42929c98, and 53a01bcc for the fix.

Detection Methods for CVE-2026-64232

Indicators of Compromise

Kernel panic messages referencing blk_rq_map_integrity_sg in the call trace
BUG_ON assertion failure with the pattern segments > rq->nr_integrity_segments
Sudden unavailability of storage nodes running dm-multipath over nvme-rdma with T10 PI enabled

Detection Strategies

Inventory Linux hosts running affected kernel versions with stacked block drivers and data integrity extensions enabled.
Monitor /var/log/kern.log, dmesg, and journalctl -k output for panics matching the block integrity assertion signature.
Correlate storage node reboots with I/O bursts on multipath devices backing NVMe-oF targets.

Monitoring Recommendations

Ingest kernel logs and node availability telemetry into a centralized SIEM or data lake for pattern matching across the fleet.
Alert on unexpected reboots or panic strings on hosts serving as NVMe-oF or multipath storage endpoints.
Track kernel version drift across nodes to identify systems missing the upstream patches referenced above.

How to Mitigate CVE-2026-64232

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in commits 0943f81e, 2c6e6a18, 42929c98, and 53a01bcc on all affected hosts.
Prioritize patching storage nodes that combine dm-multipath with nvme-rdma and T10 Protection Information.
Reboot patched systems to load the corrected block layer code.

Patch Information

The upstream fix mirrors the existing nr_phys_segments handling. When a cloned request carries integrity metadata, blk_insert_cloned_request() now recomputes nr_integrity_segments against the bottom queue using blk_rq_count_integrity_sg() and rejects the request if it exceeds queue_max_integrity_segments(). Distribution vendors typically backport this change to their stable and long-term support kernel branches; consult your distribution's advisory tracker for build availability.

Workarounds

Where patching is not immediately feasible, disable data integrity (T10 PI/DIF) on affected block devices to bypass the vulnerable code path.
Avoid stacking configurations that combine top-level queues with looser integrity segment limits over bottom queues with tighter constraints.
Restrict submission of high-fragmentation I/O to affected multipath targets until patched kernels are deployed.

bash

# Verify running kernel and check for the fix commits in distribution changelog
uname -r
rpm -q --changelog kernel | grep -E '0943f81e|2c6e6a18|42929c98|53a01bcc'
# On Debian/Ubuntu
apt changelog linux-image-$(uname -r) | grep -E '0943f81e|2c6e6a18|42929c98|53a01bcc'