All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Miguel Gazquez (Schneider Electric)" <miguel.gazquez@bootlin.com>
Cc: stable@vger.kernel.org, Christoph Hellwig <hch@infradead.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	linux-kernel@vger.kernel.org,
	Joanne Koong <joannelkoong@gmail.com>,
	syzbot@syzkaller.appspotmail.com,
	Brian Foster <bfoster@redhat.com>, Christoph Hellwig <hch@lst.de>,
	Christian Brauner <brauner@kernel.org>,
	Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 5.10.y] iomap: adjust read range correctly for non-block-aligned positions
Date: Mon, 24 Aug 2026 15:52:45 +0200	[thread overview]
Message-ID: <2026082434-freeway-legwarmer-84e6@gregkh> (raw)
In-Reply-To: <20260820-cve-2025-68974-5-10-v1-1-26ff0db1f8e8@bootlin.com>

On Thu, Aug 20, 2026 at 07:03:07PM +0200, Miguel Gazquez (Schneider Electric) wrote:
> From: Joanne Koong <joannelkoong@gmail.com>
> 
> [ Upstream commit 7aa6bc3e8766990824f66ca76c19596ce10daf3e ]
> 
> iomap_adjust_read_range() assumes that the position and length passed in
> are block-aligned. This is not always the case however, as shown in the
> syzbot generated case for erofs. This causes too many bytes to be
> skipped for uptodate blocks, which results in returning the incorrect
> position and length to read in. If all the blocks are uptodate, this
> underflows length and returns a position beyond the folio.
> 
> Fix the calculation to also take into account the block offset when
> calculating how many bytes can be skipped for uptodate blocks.
> 
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> Tested-by: syzbot@syzkaller.appspotmail.com
> Reviewed-by: Brian Foster <bfoster@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> Signed-off-by: Miguel Gazquez (Schneider Electric) <miguel.gazquez@bootlin.com>
> ---
>  fs/iomap/buffered-io.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)

Don't we also need this for 5.15.y first?

thanks,

greg k-h

  reply	other threads:[~2026-08-24 13:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 17:03 [PATCH 5.10.y] iomap: adjust read range correctly for non-block-aligned positions Miguel Gazquez (Schneider Electric)
2026-08-24 13:52 ` Greg KH [this message]
2026-08-25 11:49   ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026082434-freeway-legwarmer-84e6@gregkh \
    --to=greg@kroah.com \
    --cc=bfoster@redhat.com \
    --cc=brauner@kernel.org \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=joannelkoong@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=miguel.gazquez@bootlin.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=syzbot@syzkaller.appspotmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.