FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[gregkh]

The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 8c2f1288250a90a4b5cabed5d888d7e3aeed4035 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas@wunner.de>
Date: Sun, 12 Apr 2026 16:19:47 +0200
Subject: [PATCH] lib/crypto: mpi: Fix integer underflow in
 mpi_read_raw_from_sgl()

Yiming reports an integer underflow in mpi_read_raw_from_sgl() when
subtracting "lzeros" from the unsigned "nbytes".

For this to happen, the scatterlist "sgl" needs to occupy more bytes
than the "nbytes" parameter and the first "nbytes + 1" bytes of the
scatterlist must be zero.  Under these conditions, the while loop
iterating over the scatterlist will count more zeroes than "nbytes",
subtract the number of zeroes from "nbytes" and cause the underflow.

When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally
introduced the bug, it couldn't be triggered because all callers of
mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to
"nbytes".

However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto
interface without scatterlists"), the underflow can now actually be
triggered.  When invoking a KEYCTL_PKEY_ENCRYPT system call with a
larger "out_len" than "in_len" and filling the "in" buffer with zeroes,
crypto_akcipher_sync_prep() will create an all-zero scatterlist used for
both the "src" and "dst" member of struct akcipher_request and thereby
fulfil the conditions to trigger the bug:

  sys_keyctl()
    keyctl_pkey_e_d_s()
      asymmetric_key_eds_op()
        software_key_eds_op()
          crypto_akcipher_sync_encrypt()
            crypto_akcipher_sync_prep()
              crypto_akcipher_encrypt()
                rsa_enc()
                  mpi_read_raw_from_sgl()

To the user this will be visible as a DoS as the kernel spins forever,
causing soft lockup splats as a side effect.

Fix it.

Reported-by: Yiming Qian <yimingqian591@gmail.com> # off-list
Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: Ignat Korchagin <ignat@linux.win>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/59eca92ff4f87e2081777f1423a0efaaadcfdb39.1776003111.git.lukas@wunner.de
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

diff --git a/lib/crypto/mpi/mpicoder.c b/lib/crypto/mpi/mpicoder.c
index bf716a03c704..9359a58c29ec 100644
--- a/lib/crypto/mpi/mpicoder.c
+++ b/lib/crypto/mpi/mpicoder.c
@@ -347,7 +347,7 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
 	lzeros = 0;
 	len = 0;
 	while (nbytes > 0) {
-		while (len && !*buff) {
+		while (len && !*buff && lzeros < nbytes) {
 			lzeros++;
 			len--;
 			buff++;

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Eric Biggers]

[+Cc linux-crypto@vger.kernel.org]

On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> 
> The patch below does not apply to the 6.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> To reproduce the conflict and resubmit, you may use the following commands:
> 
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> git checkout FETCH_HEAD
> git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> # <resolve conflicts, build, test, etc.>
> git commit -s
> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> 
> Possible dependencies:

A couple issues.  First, this email wasn't sent to the subsystem's
mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
reduces the number of people who are made aware that this didn't get
automatically backported.

Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
conflict.  (The file being changed was renamed between 6.1 and 6.6, but
'git cherry-pick' handles that automatically.)

I don't know what you're doing exactly that caused it to be
unnecessarily marked as FAILED.  But whatever it is, it's not working,
and it is causing backports to be missed.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Greg KH]

On Tue, May 12, 2026 at 07:51:30PM -0700, Eric Biggers wrote:
> [+Cc linux-crypto@vger.kernel.org]
> 
> On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 6.1-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > To reproduce the conflict and resubmit, you may use the following commands:
> > 
> > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> > git checkout FETCH_HEAD
> > git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > # <resolve conflicts, build, test, etc.>
> > git commit -s
> > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > 
> > Possible dependencies:
> 
> A couple issues.  First, this email wasn't sent to the subsystem's
> mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> reduces the number of people who are made aware that this didn't get
> automatically backported.

We never send out these FAILED emails to the mailing lists, as that
would make just even more noise.  It's always been this way, sorry.

> Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> 'git cherry-pick' handles that automatically.)
> 
> I don't know what you're doing exactly that caused it to be
> unnecessarily marked as FAILED.  But whatever it is, it's not working,
> and it is causing backports to be missed.

We don't use git for cherry-picking as we have a patch queue, so renames
will often times fail, like it did here.  This has always been the case
in the decades we have been running the stable kernels :)

thanks,

greg k-h

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Eric Biggers]

On Wed, May 13, 2026 at 12:34:38PM +0200, Greg KH wrote:
> On Tue, May 12, 2026 at 07:51:30PM -0700, Eric Biggers wrote:
> > [+Cc linux-crypto@vger.kernel.org]
> > 
> > On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> > > 
> > > The patch below does not apply to the 6.1-stable tree.
> > > If someone wants it applied there, or to any other stable or longterm
> > > tree, then please email the backport, including the original git commit
> > > id to <stable@vger.kernel.org>.
> > > 
> > > To reproduce the conflict and resubmit, you may use the following commands:
> > > 
> > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> > > git checkout FETCH_HEAD
> > > git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > > # <resolve conflicts, build, test, etc.>
> > > git commit -s
> > > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > > 
> > > Possible dependencies:
> > 
> > A couple issues.  First, this email wasn't sent to the subsystem's
> > mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> > reduces the number of people who are made aware that this didn't get
> > automatically backported.
> 
> We never send out these FAILED emails to the mailing lists, as that
> would make just even more noise.  It's always been this way, sorry.

Yes, this has been a problem for a long time, resulting in lots of
missed backports including the copy.fail ones.  It's time for you to fix
your process.

> > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> > 'git cherry-pick' handles that automatically.)
> > 
> > I don't know what you're doing exactly that caused it to be
> > unnecessarily marked as FAILED.  But whatever it is, it's not working,
> > and it is causing backports to be missed.
> 
> We don't use git for cherry-picking as we have a patch queue, so renames
> will often times fail, like it did here.  This has always been the case
> in the decades we have been running the stable kernels :)

Again, this has been a problem for a long time, and it's time for you to
fix your process.  You can still have the patch queue; just use git for
the actual cherry-pick.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Eric Biggers]

On Wed, May 13, 2026 at 10:04:47AM -0700, Eric Biggers wrote:
> > > A couple issues.  First, this email wasn't sent to the subsystem's
> > > mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> > > reduces the number of people who are made aware that this didn't get
> > > automatically backported.
> > 
> > We never send out these FAILED emails to the mailing lists, as that
> > would make just even more noise.  It's always been this way, sorry.
> 
> Yes, this has been a problem for a long time, resulting in lots of
> missed backports including the copy.fail ones.  It's time for you to fix
> your process.
> 
> > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> > > 'git cherry-pick' handles that automatically.)
> > > 
> > > I don't know what you're doing exactly that caused it to be
> > > unnecessarily marked as FAILED.  But whatever it is, it's not working,
> > > and it is causing backports to be missed.
> > 
> > We don't use git for cherry-picking as we have a patch queue, so renames
> > will often times fail, like it did here.  This has always been the case
> > in the decades we have been running the stable kernels :)
> 
> Again, this has been a problem for a long time, and it's time for you to
> fix your process.  You can still have the patch queue; just use git for
> the actual cherry-pick.

Also I should mention that your own instructions for "reproducing" the
conflict use 'git cherry-pick':

    git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
    git checkout FETCH_HEAD
    git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
    # <resolve conflicts, build, test, etc.>
    git commit -s
    git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..

When these instructions are followed, there is no conflict.  The
"conflict" is purely because you didn't use 'git cherry-pick' yourself.

So just start using 'git cherry-pick', and stop asking other people to
do it for you when there are no conflicts, please.

And please start Cc'ing the mailing lists.  Linux kernel development
isn't done in private email.  I would have backported the copy.fail
fixes earlier, but I never received the FAILED emails (which I'm
guessing you sent, but only in private email to other people), so I
didn't know they weren't being backported...

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Greg KH]

On Wed, May 13, 2026 at 10:59:34PM +0000, Eric Biggers wrote:
> On Wed, May 13, 2026 at 10:04:47AM -0700, Eric Biggers wrote:
> > > > A couple issues.  First, this email wasn't sent to the subsystem's
> > > > mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> > > > reduces the number of people who are made aware that this didn't get
> > > > automatically backported.
> > > 
> > > We never send out these FAILED emails to the mailing lists, as that
> > > would make just even more noise.  It's always been this way, sorry.
> > 
> > Yes, this has been a problem for a long time, resulting in lots of
> > missed backports including the copy.fail ones.  It's time for you to fix
> > your process.
> > 
> > > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > > conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> > > > 'git cherry-pick' handles that automatically.)
> > > > 
> > > > I don't know what you're doing exactly that caused it to be
> > > > unnecessarily marked as FAILED.  But whatever it is, it's not working,
> > > > and it is causing backports to be missed.
> > > 
> > > We don't use git for cherry-picking as we have a patch queue, so renames
> > > will often times fail, like it did here.  This has always been the case
> > > in the decades we have been running the stable kernels :)
> > 
> > Again, this has been a problem for a long time, and it's time for you to
> > fix your process.  You can still have the patch queue; just use git for
> > the actual cherry-pick.
> 
> Also I should mention that your own instructions for "reproducing" the
> conflict use 'git cherry-pick':
> 
>     git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
>     git checkout FETCH_HEAD
>     git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
>     # <resolve conflicts, build, test, etc.>
>     git commit -s
>     git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> 
> When these instructions are followed, there is no conflict.  The
> "conflict" is purely because you didn't use 'git cherry-pick' yourself.

Yes, that is true, we are showing how someone else can potentially
resolve the issue.  The magic is in the line:
	# <resolve conflicts, build, test, etc.>

We issue FAILED emails for any number of reasons, we don't go into the
details of why it FAILED, otherwise we would have just too much
information here.

> So just start using 'git cherry-pick', and stop asking other people to
> do it for you when there are no conflicts, please.

That does not work in our workflow at all.  Given the huge flow of
patches, and all the different issues/errors, the odds that a simple
rename will resolve the problem is very low.  For that I can not slow
down the whole process for all submissions.

> And please start Cc'ing the mailing lists.  Linux kernel development
> isn't done in private email.

This isn't a private list, we are cc:ing the people who signed off on
the patch directly.  They are the "owners" of it.

> I would have backported the copy.fail
> fixes earlier, but I never received the FAILED emails (which I'm
> guessing you sent, but only in private email to other people), so I
> didn't know they weren't being backported...

Those patches were NOT marked for stable inclusion, so they did not get
a FAILED email at all.  We were lucky that Sasha's sweep of the tree for
"random patches that have a Fixes: tag only that look interesting"
actually caught them for a few branches.  And for those, we NEVER send a
FAILED email either, as the maintainer did not explicitly ask us for
stable inclusion, so we are not going to bother them with extra stuff.

thanks,

greg k-h

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Eric Biggers]

On Fri, May 15, 2026 at 07:45:40AM +0200, Greg KH wrote:
> On Wed, May 13, 2026 at 10:59:34PM +0000, Eric Biggers wrote:
> > On Wed, May 13, 2026 at 10:04:47AM -0700, Eric Biggers wrote:
> > > > > A couple issues.  First, this email wasn't sent to the subsystem's
> > > > > mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> > > > > reduces the number of people who are made aware that this didn't get
> > > > > automatically backported.
> > > > 
> > > > We never send out these FAILED emails to the mailing lists, as that
> > > > would make just even more noise.  It's always been this way, sorry.
> > > 
> > > Yes, this has been a problem for a long time, resulting in lots of
> > > missed backports including the copy.fail ones.  It's time for you to fix
> > > your process.
> > > 
> > > > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > > > conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> > > > > 'git cherry-pick' handles that automatically.)
> > > > > 
> > > > > I don't know what you're doing exactly that caused it to be
> > > > > unnecessarily marked as FAILED.  But whatever it is, it's not working,
> > > > > and it is causing backports to be missed.
> > > > 
> > > > We don't use git for cherry-picking as we have a patch queue, so renames
> > > > will often times fail, like it did here.  This has always been the case
> > > > in the decades we have been running the stable kernels :)
> > > 
> > > Again, this has been a problem for a long time, and it's time for you to
> > > fix your process.  You can still have the patch queue; just use git for
> > > the actual cherry-pick.
> > 
> > Also I should mention that your own instructions for "reproducing" the
> > conflict use 'git cherry-pick':
> > 
> >     git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> >     git checkout FETCH_HEAD
> >     git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> >     # <resolve conflicts, build, test, etc.>
> >     git commit -s
> >     git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > 
> > When these instructions are followed, there is no conflict.  The
> > "conflict" is purely because you didn't use 'git cherry-pick' yourself.
> 
> Yes, that is true, we are showing how someone else can potentially
> resolve the issue.  The magic is in the line:
>
> 	# <resolve conflicts, build, test, etc.>
> 
> We issue FAILED emails for any number of reasons, we don't go into the
> details of why it FAILED, otherwise we would have just too much
> information here.

I'm not asking for details on why it's FAILED.  I'm asking for commits
that cherry-pick cleanly to not be FAILED in the first place.

> > So just start using 'git cherry-pick', and stop asking other people to
> > do it for you when there are no conflicts, please.
> 
> That does not work in our workflow at all.  Given the huge flow of
> patches, and all the different issues/errors, the odds that a simple
> rename will resolve the problem is very low.  For that I can not slow
> down the whole process for all submissions.

I've been doing stable backports for a long time, and it's happened
*many* times that something cherry-picks cleanly for me but you say
there are "conflicts".  Here's an example from just 2 weeks ago where
you spent time "resolving" a "conflict" in commits that actually
cherry-picked cleanly:
https://lore.kernel.org/linux-crypto/2026043050-drainpipe-salvage-07c1@gregkh/

> > And please start Cc'ing the mailing lists.  Linux kernel development
> > isn't done in private email.
> 
> This isn't a private list, we are cc:ing the people who signed off on
> the patch directly.  They are the "owners" of it.

And sometimes the "owners" don't do it and other people involved in the
subsystem need to do it.  Or the backports are wrong and other people
involved in the system need to point that out.  It's not much different
from any other kernel development; it should be done on the lists.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Greg KH]

On Wed, May 13, 2026 at 10:04:45AM -0700, Eric Biggers wrote:
> On Wed, May 13, 2026 at 12:34:38PM +0200, Greg KH wrote:
> > On Tue, May 12, 2026 at 07:51:30PM -0700, Eric Biggers wrote:
> > > [+Cc linux-crypto@vger.kernel.org]
> > > 
> > > On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> > > > 
> > > > The patch below does not apply to the 6.1-stable tree.
> > > > If someone wants it applied there, or to any other stable or longterm
> > > > tree, then please email the backport, including the original git commit
> > > > id to <stable@vger.kernel.org>.
> > > > 
> > > > To reproduce the conflict and resubmit, you may use the following commands:
> > > > 
> > > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> > > > git checkout FETCH_HEAD
> > > > git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > > > # <resolve conflicts, build, test, etc.>
> > > > git commit -s
> > > > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > > > 
> > > > Possible dependencies:
> > > 
> > > A couple issues.  First, this email wasn't sent to the subsystem's
> > > mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> > > reduces the number of people who are made aware that this didn't get
> > > automatically backported.
> > 
> > We never send out these FAILED emails to the mailing lists, as that
> > would make just even more noise.  It's always been this way, sorry.
> 
> Yes, this has been a problem for a long time, resulting in lots of
> missed backports including the copy.fail ones.  It's time for you to fix
> your process.
> 
> > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> > > 'git cherry-pick' handles that automatically.)
> > > 
> > > I don't know what you're doing exactly that caused it to be
> > > unnecessarily marked as FAILED.  But whatever it is, it's not working,
> > > and it is causing backports to be missed.
> > 
> > We don't use git for cherry-picking as we have a patch queue, so renames
> > will often times fail, like it did here.  This has always been the case
> > in the decades we have been running the stable kernels :)
> 
> Again, this has been a problem for a long time, and it's time for you to
> fix your process.  You can still have the patch queue; just use git for
> the actual cherry-pick.

Doesn't work well unless we turn the patch queue into a git tree at
every step of the way :(