linux-kernel - Re: [PATCH 1/2] iov_iter: iterate_folioq: fix handling of offset >= folio size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <385673.1754923063@warthog.procyon.org.uk>
Date: Mon, 11 Aug 2025 15:37:43 +0100
From: David Howells <dhowells@...hat.com>
To: asmadeus@...ewreck.org
Cc: dhowells@...hat.com, "Matthew Wilcox (Oracle)" <willy@...radead.org>,
    Christian Brauner <brauner@...nel.org>,
    Alexander Viro <viro@...iv.linux.org.uk>,
    Andrew Morton <akpm@...ux-foundation.org>,
    Maximilian Bosch <maximilian@...sch.me>, Ryan Lahfa <ryan@...fa.xyz>,
    Christian Theune <ct@...ingcircus.io>,
    Arnout Engelen <arnout@...t.net>, linux-kernel@...r.kernel.org,
    linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
    stable@...r.kernel.org
Subject: Re: [PATCH 1/2] iov_iter: iterate_folioq: fix handling of offset >= folio size

Dominique Martinet via B4 Relay wrote:

> It's apparently possible to get an iov forwarded all the way up to the

By "forwarded" I presume you mean "advanced"?

> end of the current page we're looking at, e.g.
> 
> (gdb) p *iter
> $24 = {iter_type = 4 '\004', nofault = false, data_source = false, iov_offset = 4096, {__ubuf_iovec = {
>       iov_base = 0xffff88800f5bc000, iov_len = 655}, {{__iov = 0xffff88800f5bc000, kvec = 0xffff88800f5bc000,
>         bvec = 0xffff88800f5bc000, folioq = 0xffff88800f5bc000, xarray = 0xffff88800f5bc000,
>         ubuf = 0xffff88800f5bc000}, count = 655}}, {nr_segs = 2, folioq_slot = 2 '\002', xarray_start = 2}}
> 
> Where iov_offset is 4k with 4k-sized folios
> 
> This should have been because we're only in the 2nd slot and there's
> another one after this, but iterate_folioq should not try to map a
> folio that skips the whole size, and more importantly part here does
> not end up zero (because 'PAGE_SIZE - skip % PAGE_SIZE' ends up
> PAGE_SIZE and not zero..), so skip forward to the "advance to next
> folio" code.

Note that things get complicated because folioqs form a segmented list that
can be under construction as it advances.  So if there's no next folioq
segment at the time you advance to the end of the current one, it will end up
parked at the end of the last folio or with slot==nr_slots because there's
nowhere for it to advance to.  However, the folioq chain can then get
extended, so the advancer has to detect this and move on to the next segment.

Anyway:

Acked-by: David Howells <dhowells@...hat.com>

Note that extract_folioq_to_sg() already does this as does
iov_iter_extract_folioq_pages().