When extracting from a kvec to a scatterlist, do not
cross page boundaries. The required length is already
calculated but not used as intended.

The previous changes to the kunit_iov_iter.c demonstrate
that the patch is necessary.

Cc: David Howells <dhowells@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@vger.kernel.org # v6.5+
Fixes: 018584697533 ("netfs: Add a function to extract an iterator into a scatterlist")
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
---
 lib/scatterlist.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 21bc9c1f7c06..73893ee0d92d 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -1249,7 +1249,7 @@ static ssize_t extract_kvec_to_sg(struct iov_iter *iter,
 			else
 				page = virt_to_page((void *)kaddr);
 
-			sg_set_page(sg, page, len, off);
+			sg_set_page(sg, page, seg, off);
 			sgtable->nents++;
 			sg++;
 			sg_max--;
-- 
2.43.0

On Mon, 23 Mar 2026 22:23:50 +0100 "Christian A. Ehrhardt" <lk@c--e.de> wrote:

> When extracting from a kvec to a scatterlist, do not
> cross page boundaries. The required length is already
> calculated but not used as intended.
> 
> The previous changes to the kunit_iov_iter.c demonstrate
> that the patch is necessary.
> 
> Cc: David Howells <dhowells@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: stable@vger.kernel.org # v6.5+

But 018584697533 was first released in 6.10?

I'll remove the " v6.5+" - it isn't needed when we have the Fixes: hash.

But please do check that 018584697533 was the correct target.

> Fixes: 018584697533 ("netfs: Add a function to extract an iterator into a scatterlist")

Hi Andrew,

On Tue, Mar 24, 2026 at 12:15:52PM -0700, Andrew Morton wrote:
> On Mon, 23 Mar 2026 22:23:50 +0100 "Christian A. Ehrhardt" <lk@c--e.de> wrote:
> 
> > When extracting from a kvec to a scatterlist, do not
> > cross page boundaries. The required length is already
> > calculated but not used as intended.
> > 
> > The previous changes to the kunit_iov_iter.c demonstrate
> > that the patch is necessary.
> > 
> > Cc: David Howells <dhowells@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: stable@vger.kernel.org # v6.5+
> 
> But 018584697533 was first released in 6.10?

No, it was first in 6.3:
| $ git log v6.3 | grep -A3 "commit 018584697533"
| commit 0185846975339a5c348373aa450a977f5242366b
| Author: David Howells <dhowells@redhat.com>
| Date:   Thu Oct 27 16:19:44 2022 +0100


> I'll remove the " v6.5+" - it isn't needed when we have the Fixes: hash.

Please don't. The patch will only apply without modification
for v6.5+ because the function was moved to a different file.
As the only stable kernels in that range are 6.1 and 6.6 the
v6.5+ should be sufficient?

> But please do check that 018584697533 was the correct target.

It is, see above.

I have an updated verion of the series almost ready that addresses
some of the AI review comments. Should I send an updated version or
incremental patches?

Best regards,
Christian

On Tue, 24 Mar 2026 20:47:01 +0100 "Christian A. Ehrhardt" <lk@c--e.de> wrote:

> 
> Hi Andrew,
> 
> On Tue, Mar 24, 2026 at 12:15:52PM -0700, Andrew Morton wrote:
> > On Mon, 23 Mar 2026 22:23:50 +0100 "Christian A. Ehrhardt" <lk@c--e.de> wrote:
> > 
> > > When extracting from a kvec to a scatterlist, do not
> > > cross page boundaries. The required length is already
> > > calculated but not used as intended.
> > > 
> > > The previous changes to the kunit_iov_iter.c demonstrate
> > > that the patch is necessary.
> > > 
> > > Cc: David Howells <dhowells@redhat.com>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Cc: stable@vger.kernel.org # v6.5+
> > 
> > But 018584697533 was first released in 6.10?
> 
> No, it was first in 6.3:
> | $ git log v6.3 | grep -A3 "commit 018584697533"
> | commit 0185846975339a5c348373aa450a977f5242366b
> | Author: David Howells <dhowells@redhat.com>
> | Date:   Thu Oct 27 16:19:44 2022 +0100

hp2:/usr/src/mm> git show --pretty=fuller 018584697533 | head -n10
commit 0185846975339a5c348373aa450a977f5242366b
Author:     David Howells <dhowells@redhat.com>
AuthorDate: Thu Oct 27 16:19:44 2022 +0100
Commit:     Steve French <stfrench@microsoft.com>
CommitDate: Mon Feb 20 17:25:43 2023 -0600

It obviously got stalled somewhere for a while.

> 
> > I'll remove the " v6.5+" - it isn't needed when we have the Fixes: hash.
> 
> Please don't. The patch will only apply without modification
> for v6.5+ because the function was moved to a different file.
> As the only stable kernels in that range are 6.1 and 6.6 the
> v6.5+ should be sufficient?

hp2:/usr/src/mm> git tag --contains 018584697533 | grep "^v[0-9]*" | head 
v6.10
v6.10-rc1
v6.10-rc2
v6.10-rc3
v6.10-rc4
v6.10-rc5
v6.10-rc6
v6.10-rc7
v6.11

> > But please do check that 018584697533 was the correct target.
> 
> It is, see above.
> 
> I have an updated verion of the series almost ready that addresses
> some of the AI review comments. Should I send an updated version or
> incremental patches?

A new series will work, thanks.

On Mon, 23 Mar 2026 22:23:50 +0100 "Christian A. Ehrhardt" <lk@c--e.de> wrote:

> When extracting from a kvec to a scatterlist, do not
> cross page boundaries. The required length is already
> calculated but not used as intended.
> 
> The previous changes to the kunit_iov_iter.c demonstrate
> that the patch is necessary.

Thanks.

> Cc: David Howells <dhowells@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: stable@vger.kernel.org # v6.5+

Could we please have a description of the userspace-visible impact?  To
help others understand why we're proposing a backport,

> --- a/lib/scatterlist.c
> +++ b/lib/scatterlist.c
> @@ -1249,7 +1249,7 @@ static ssize_t extract_kvec_to_sg(struct iov_iter *iter,
>  			else
>  				page = virt_to_page((void *)kaddr);
>  
> -			sg_set_page(sg, page, len, off);
> +			sg_set_page(sg, page, seg, off);
>  			sgtable->nents++;
>  			sg++;
>  			sg_max--;

I'm thinking the series should be split up - this patch for 7.0-rcX and
-stable, the kunit changes for 7.0-rcX.  Or do you think we should
-stableize the kunit changes also?

Or we put it all into 7.0-rcX and let the -stable patch trickle back
later on.  After all, 018584697533 was a couple of years ago.  It's hard
to decide on these things without that userspace-visible impact thing!

Hi Andrew,

On Tue, Mar 24, 2026 at 12:12:24PM -0700, Andrew Morton wrote:
> On Mon, 23 Mar 2026 22:23:50 +0100 "Christian A. Ehrhardt" <lk@c--e.de> wrote:
> 
> > When extracting from a kvec to a scatterlist, do not
> > cross page boundaries. The required length is already
> > calculated but not used as intended.
> > 
> > The previous changes to the kunit_iov_iter.c demonstrate
> > that the patch is necessary.
> 
> Thanks.
> 
> > Cc: David Howells <dhowells@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: stable@vger.kernel.org # v6.5+
> 
> Could we please have a description of the userspace-visible impact?  To
> help others understand why we're proposing a backport,

The function is used to construct a scatterlist. The result of the
bug is that the scatterlist entries have a length that is too long.
Results can vary but most likely this will result in silent data
corruption. I don't have a use visible example of this, though.
The bug was found while staring at code.

> > --- a/lib/scatterlist.c
> > +++ b/lib/scatterlist.c
> > @@ -1249,7 +1249,7 @@ static ssize_t extract_kvec_to_sg(struct iov_iter *iter,
> >  			else
> >  				page = virt_to_page((void *)kaddr);
> >  
> > -			sg_set_page(sg, page, len, off);
> > +			sg_set_page(sg, page, seg, off);
> >  			sgtable->nents++;
> >  			sg++;
> >  			sg_max--;
> 
> I'm thinking the series should be split up - this patch for 7.0-rcX and
> -stable, the kunit changes for 7.0-rcX.  Or do you think we should
> -stableize the kunit changes also?

Only the actual fix is marked for backport to -stable but I consider
that somewhat critical because it is in essence a memory error.

> Or we put it all into 7.0-rcX and let the -stable patch trickle back
> later on.  After all, 018584697533 was a couple of years ago.  It's hard
> to decide on these things without that userspace-visible impact thing!

Best regards,
Christian