Re: [patch 1/1] iov_iter: validate extracted segment for bvec alignment

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 20 Oct 2026 11:43:32 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> From: Daehyeon Ko <4ncienth@gmail.com>
> Subject: iov_iter: validate extracted segment for bvec alignment
> Date: Thu, 15 Oct 2026 15:19:07 +0900
> 
> iov_iter_extract_bvecs() validates iter_iov_addr() and iter_iov_len()
> before iov_iter_extract_pages() selects the first nonempty segment and
> limits it by iter->count.  The checks can therefore cover a different
> range after a leading empty segment or iov_iter_truncate().
> 
> An unprivileged O_DIRECT preadv() reproduced the empty-segment case: an
> aligned empty segment followed by a misaligned one completed 4096 bytes
> instead of returning -EINVAL.  A truncated iterator has the same mismatch
> when its full segment length is aligned but its remaining count is not.
> 
> The worst effect I have confirmed is an alignment-contract bypass.  An
> unprivileged O_DIRECT preadv() produced bvecs with offset/length pairs
> (1, 4095) and (0, 1).  The bio reached brd_submit_bio(), and the read
> completed 4096 bytes instead of failing with -EINVAL.
> 
> I have not demonstrated harmful behavior on real DMA hardware.  For a
> normal blk-mq target, blk_mq_submit_bio() calls
> __bio_split_to_limits(), where bio_split_io_at() rejects the misaligned
> bvec before queue_rq().  Virtio-blk and loop both returned -EINVAL in
> my controls.
> 
> So a bio-based driver can receive a bvec which violates its advertised
> dma_alignment, but any further effect is driver-specific.  I have not
> reproduced memory corruption or a crash on real hardware.
> 
> Bound the normal fast-path length by iter->count.  Keep
> first_iovec_segment() for leading empty segments so validation covers the
> remaining portion of the segment available for extraction.

I guess I should have added

Tested-by: Andrew Morton <akpm@linux-foundation.org>	#writev() only


I tested this against the ext4 writev() KASAN reproducer.  The
unpatched kernel triggered a slab out-of-bounds read and returned 1015
bytes.  With the patch applied, writev() returned the expected 1025
bytes without a KASAN report.  But I didn't test the preadv() path.