CVE-2026-89584

What it actually does

The Linux kernel block layer did not validate that userspace I/O vectors meet a device's dma_alignment when a bio is built from an iov_iter. Bio-based drivers often skip alignment splits, and stacking drivers may not handle misalignment discovered only after bio submission, so misaligned buffers can reach DMA mapping and I/O completion. That can corrupt kernel memory, panic the host, or yield a local code-execution or privilege-escalation primitive (High CIA impact on the kernel).

Why it matters to the business

Any Linux host where untrusted local users can open block or stacked-block devices can be crashed or fully taken over, causing outages and loss of host integrity. The kernel is nearly universal, so blast radius is large even without a listed dependent count. The issue is not in CISA KEV, has no known ransomware use, exploit maturity is none, and EPSS is low and flat (~0.00165 over 30 days), so opportunistic mass exploitation is unlikely today; still patch promptly because a single local foothold can become kernel control.

How an attack unfolds

An attacker who already has a local unprivileged account targets a bio-based or stacking block device. They submit vectored userspace I/O whose buffer addresses or lengths violate the device dma_alignment. The kernel constructs a bio without rejecting those vectors, then submits it. Drivers that do not re-check alignment perform misaligned DMA or fail while splitting the bio, producing a kernel oops, memory corruption, or an exploitable primitive the attacker tries to convert into denial of service or root. No public exploit, named threat actor, or KEV campaign is associated with this flaw.

How to fix it

Install a Linux kernel that includes the fix 'block: validate user space vectors during extraction', which checks userspace vectors against the device dma_alignment while the bio is built from the iov_iter and fails the request early with -EINVAL. This record lists no package-specific fixed versions, so take the patched kernel from your distribution or stable tree, deploy it, and reboot. Until then, deny untrusted users access to raw, loop, device-mapper, and other stacking block devices via groups, udev, and LSM policy.

How to confirm the fix worked

Confirm the running kernel changelog or stable git history contains the dma_alignment check during bio extraction from iov_iter, then reboot onto that kernel. After the fix, misaligned vectored I/O to a block device should return EINVAL and must not reach the driver. Inventory remaining pre-fix kernels and review dmesg/journal for leftover block-layer oopses or DMA mapping failures.

Typical attack path

1. Gain local unprivileged execution on a Linux system with access to a block or stacked-block device.
2. Choose a bio-based or stacking target whose driver does not re-validate DMA alignment after bio submission.
3. Submit vectored userspace I/O with buffers that violate the device dma_alignment.
4. Allow the kernel to build a bio from the iov_iter without early rejection.
5. Trigger driver processing of the misaligned bio to cause a crash or kernel-memory corruption.
6. If corruption is achieved, attempt to escalate to kernel/root or leave the host in a denied-service state.

How to detect it

No public exploit or named actor activity is known, so detection is retrospective host forensics rather than malware IOCs. Search kernel logs (journald, kmsg, dmesg), kdump/vmcore, and panic records for oopses, BUGs, or DMA mapping failures in bio, iov_iter, block, or stacking-driver paths, especially from processes issuing vectored I/O to block devices. Post-fix EINVAL on misaligned I/O is intended fail-closed behavior, not compromise. Lack of crash artifacts does not prove the bug was never hit.

What your security team should do

• Patch and reboot Linux hosts, starting with multi-tenant, developer, and CI systems where local users can reach block devices, despite low EPSS and no KEV listing.
• Until vendor kernels are installed, restrict open/read/write on raw and stacked block devices for untrusted accounts.
• Track distribution backport status; this advisory does not name exact fixed versions.
• Hunt historical kernel logs and crash dumps for block/bio/DMA oopses that could indicate triggering.
• Treat residual unpatched kernels as a local privilege-escalation exposure in risk reporting.