CVE-2026-98821 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
block: reject polled dio with user integrity metadata
IOCB_HAS_METADATA leaves iocb->private as a uio_meta, while iocb_bio_iopoll() expects a bio. Since 2729a60bbfb9, metadata I/O always uses __blkdev_direct_IO(), which never publishes the bio for polling, so IOPOLL calls bio_poll() on the uio_meta.
Reproducer: io_uring IOPOLL plus a PI attribute on an integrity device (scsi_debug dif=1 dix=1). KASAN reports:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
RIP: 0010:bio_poll+0x9d/0x4b0 Call Trace: iocb_bio_iopoll+0x5b/0x80 io_uring_classic_poll+0xf3/0x140 io_do_iopoll+0x4e3/0xc00 io_iopoll_check+0x275/0x560 __do_sys_io_uring_enter+0x2e5/0x720
Return -EOPNOTSUPP when HIPRI is combined with user metadata.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The Linux kernel block layer contains a critical type confusion vulnerability that arises from the incorrect handling of polled direct I/O operations involving user integrity metadata. This flaw specifically affects systems utilizing io_uring with high-priority polling (IOPOLL) and devices configured for data integrity information, such as SCSI devices with DIF enabled. The root cause lies in a mismatch between how input/output control blocks are structured when metadata is involved versus what the kernel's polling mechanism expects to process. When an I/O operation includes user integrity metadata, indicated by the IOCB_HAS_METADATA flag, the private field of the io_uring completion queue entry or related structure holds a pointer to a uio_meta object rather than a standard bio structure. However, the function responsible for handling polled I/O completions, iocb_bio_iopoll(), is designed under the assumption that this private field always contains a valid bio pointer. This architectural inconsistency creates a dangerous scenario where type confusion occurs during execution.
The vulnerability was exacerbated by commit 2729a60bbfb9, which changed metadata I/O operations to exclusively use __blkdev_direct_IO(). While this change improved performance and consistency for direct I/O paths, it inadvertently broke the polling mechanism because __blkdev_direct_IO() does not publish a bio structure when handling integrity metadata. Consequently, when an application requests polled completion via io_uring with high priority settings combined with user-provided integrity attributes, the kernel attempts to dereference what it believes is a bio pointer but is actually a uio_meta struct. This leads to accessing memory at incorrect offsets within the object layout, resulting in invalid memory access patterns that trigger general protection faults or null-pointer dereferences as reported by Kernel Address Sanitizer tools.
From an operational perspective, this vulnerability allows for local denial of service attacks against systems running vulnerable kernel versions. An unprivileged user with appropriate io_uring permissions can craft specific I/O requests that exploit this type confusion to crash the system or cause unpredictable behavior within the block layer subsystems. The impact is particularly severe in environments where high-performance storage operations are critical, as repeated exploitation could lead to frequent kernel panics and service interruptions. Furthermore, because the issue involves memory corruption through invalid pointer dereferences, there may be potential for further exploitation if adjacent memory structures can be influenced or read, although the primary observed effect is a crash due to non-canonical address access.
This vulnerability aligns with CWE-824, which describes access of a variable after it has been freed or reused, and more specifically reflects issues related to improper type checking in C/C++ code leading to memory corruption. In terms of attack vectors, this falls under the ATT&CK technique for exploitation via local privilege escalation paths where an attacker leverages kernel vulnerabilities to disrupt system availability. The specific mechanism involves manipulating I/O submission queues to trigger incorrect function calls within the block layer polling logic.
To mitigate this risk, developers have implemented a check that rejects polled direct I/O operations when user integrity metadata is present by returning -EOPNOTSUPP if high-priority flags are combined with such metadata requests. This effectively disables the problematic code path for these specific configurations until a more robust solution can be engineered to properly handle bio structures in the presence of integrity data during polling. System administrators should ensure that kernel updates incorporating this fix are applied promptly, particularly on systems utilizing io_uring for high-throughput storage operations with integrity features enabled. Additionally, monitoring logs for general protection faults or KASAN reports related to block layer functions can help identify potential exploitation attempts before they cause significant system instability.