FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[gregkh]

The patch below does not apply to the 6.12-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.12.y
git checkout FETCH_HEAD
git cherry-pick -x 24f07e8c07a0c0dd275331cbb41c79a78741eef9
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026102137-contently-unshaven-7da4@gregkh' --subject-prefix 'PATCH 6.12.y' 'HEAD^..'

Possible dependencies:



thanks,

greg k-h

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

From 24f07e8c07a0c0dd275331cbb41c79a78741eef9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Jean?= <Jeremy.Jean@oss.cyber.gouv.fr>
Date: Fri, 9 Oct 2026 14:53:53 +0200
Subject: [PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON
 state
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When poly1305_blocks_neon() resumes from a base 2^26 accumulator and the
next update contains an odd number of full 16-byte blocks, it processes
one leading block through poly1305_mult() so that the remaining NEON
work has an even block count.  That requires converting the accumulator
to the base 2^64 form used by poly1305_mult().  The final ADC of that
conversion stores the carry into d2, but the following accumulation and
poly1305_mult() use h2.  If the conversion carries across bit 128, the
carry is dropped and the emitted tag is wrong.

This was introduced by Cryptogams commit 03dc4adf91c8
("arm/poly1305-armv*.pl: optimize branches."), which removed the
reduction that consumed d2 shortly before Linux imported the code.
OpenSSL's copy did not take that change.

The carry is possible because the NEON code stores the accumulator [h0,
h1, h2, h3, h4] in a lazily reduced, redundant base 2^26 form: its final
carry chain leaves h0, h2, h3 < 2^26, but h1 and h4 may slightly exceed
2^26 - 1.  For example, the reachable state

  h0 = 4
  h1 = 2^26
  h2 = 2^26 - 1
  h3 = 2^26 - 1
  h4 = 2^24 - 1

represents 4 + 2^26*2^26 + (2^26-1)*2^52 + (2^26-1)*2^78 +
(2^24-1)*2^104 = 2^128 + 4, despite the bit representing the 2^128 term
(bit 24 of h4) not being set; the extra comes from the h1 limb being
above the normal base 2^26 range.  When this value is converted into the
non-redundant base 2^64 form, a carry into the new 2^128 bit (in bit 0
of h2) is necessary to preserve the value.

Given the above bounds, a carry into bit 128 happens exactly when
h1 >= 2^26, h2 = h3 = 2^26 - 1, and h4 mod 2^24 = 2^24 - 1.

Store the carry into h2, matching the other base 2^26 to base 2^64
conversions in poly1305_blocks() and poly1305_emit().

This bug causes an incorrect tag to be emitted.  However, this is
unlikely to happen in practice where Poly1305 is used with a random key,
since the random key tends to distribute the accumulator values
throughout their valid range.  There isn't an obvious way for an
attacker without knowledge of the r_key to cause [h0, h1, h2, h3, h4] to
land on the precise values where this bug occurs.

[EB: Rewrote the commit message to more clearly describe the bug and
 its impact, and simplified explanation about why there's a carry bit.]

Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Link: https://patch.msgid.link/20261009125354.315476-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

diff --git a/lib/crypto/arm64/poly1305-armv8.pl b/lib/crypto/arm64/poly1305-armv8.pl
index f1930c6b55ce..234398ff6b60 100644
--- a/lib/crypto/arm64/poly1305-armv8.pl
+++ b/lib/crypto/arm64/poly1305-armv8.pl
@@ -375,7 +375,7 @@ poly1305_blocks_neon:
 	adc	$h1,$h1,xzr
 	lsr	$h2,x14,#24
 	adds	$h1,$h1,x14,lsl#40
-	adc	$d2,$h2,xzr		// can be partially reduced...
+	adc	$h2,$h2,xzr		// preserve carry into top limb
 
 	ldp	$d0,$d1,[$inp],#16	// load input
 	sub	$len,$len,#16

Re: FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[Eric Biggers]

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

On Wed, Oct 21, 2026 at 04:40:37PM +0200, gregkh@linuxfoundation.org wrote:
> 
> The patch below does not apply to the 6.12-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>.

It's a clean cherry-pick, as git detects the rename of
poly1305-armv8.pl.  So there should be no need to require this to be
resent.  Also, missing Cc to linux-crypto.

Same for 6.12, 6.6, 6.1, 5.15, and 5.10.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[Eric Biggers]

On Wed, Oct 21, 2026 at 08:48:08AM -0700, Eric Biggers wrote:
> [+Cc linux-crypto@vger.kernel.org]
> 
> On Wed, Oct 21, 2026 at 04:40:37PM +0200, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 6.12-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>.
> 
> It's a clean cherry-pick, as git detects the rename of
> poly1305-armv8.pl.  So there should be no need to require this to be
> resent.  Also, missing Cc to linux-crypto.
> 
> Same for 6.12, 6.6, 6.1, 5.15, and 5.10.

As I've said before, the reason this keeps happening is that Greg's
stable scripts perform a cherry-pick by first formatting the commit as a
patch file with the default 3 lines of context, then applying it with
'patch' using the default fuzz of 2.

(The second step seems to occur in the 'apply_it' script, which isn't
public.  But based on the observed behavior, it must be what it does.)

This process is buggy compared to simply using 'git cherry-pick':

- It has no rename detection.  Any file rename, like what happened for
  this commit where poly1305-armv8.pl is in different locations in
  different branches, results in FAILED.  This happens regularly.

- Incorrect backports due to only *one* line of context being
  considered (since 3 - 2 = 1).  For examples of this, see
  https://lore.kernel.org/all/20260512173933.811124271@linuxfoundation.org/
  and
  https://lore.kernel.org/all/20260515154719.961677988@linuxfoundation.org/

  This is easily reproducible.  For example for the first one:

  git checkout -d v6.12.87
  git cherry-pick 2909f0d4994fb4306bf116df5ccee797791fce2c
  git show # correct backport

  git checkout -d v6.12.87
  git format-patch -1 --no-base 2909f0d4994fb4306bf116df5ccee797791fce2c
  patch -p1 < 0001-usb-typec-tcpm-reset-internal-port-states-on-soft-re.patch
  git diff # incorrect backport that was actually sent out

  The second example is even worse, as there the incorrect backport was
  actually released.

Just using 'git cherry-pick', as contributors are already being asked to
do in the FAILED emails themselves, avoids these problems.

Can this please be fixed?  This outdated cherry-pick process is reducing
the quality of the stable releases.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[Eric Biggers]

On Wed, Oct 21, 2026 at 09:48:36AM -0700, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 08:48:08AM -0700, Eric Biggers wrote:
> > [+Cc linux-crypto@vger.kernel.org]
> > 
> > On Wed, Oct 21, 2026 at 04:40:37PM +0200, gregkh@linuxfoundation.org wrote:
> > > 
> > > The patch below does not apply to the 6.12-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>.
> > 
> > It's a clean cherry-pick, as git detects the rename of
> > poly1305-armv8.pl.  So there should be no need to require this to be
> > resent.  Also, missing Cc to linux-crypto.
> > 
> > Same for 6.12, 6.6, 6.1, 5.15, and 5.10.
> 
> As I've said before, the reason this keeps happening is that Greg's
> stable scripts perform a cherry-pick by first formatting the commit as a
> patch file with the default 3 lines of context, then applying it with
> 'patch' using the default fuzz of 2.
> 
> (The second step seems to occur in the 'apply_it' script, which isn't
> public.  But based on the observed behavior, it must be what it does.)
> 
> This process is buggy compared to simply using 'git cherry-pick':
> 
> - It has no rename detection.  Any file rename, like what happened for
>   this commit where poly1305-armv8.pl is in different locations in
>   different branches, results in FAILED.  This happens regularly.
> 
> - Incorrect backports due to only *one* line of context being
>   considered (since 3 - 2 = 1).  For examples of this, see
>   https://lore.kernel.org/all/20260512173933.811124271@linuxfoundation.org/
>   and
>   https://lore.kernel.org/all/20260515154719.961677988@linuxfoundation.org/
> 
>   This is easily reproducible.  For example for the first one:
> 
>   git checkout -d v6.12.87
>   git cherry-pick 2909f0d4994fb4306bf116df5ccee797791fce2c
>   git show # correct backport
> 
>   git checkout -d v6.12.87
>   git format-patch -1 --no-base 2909f0d4994fb4306bf116df5ccee797791fce2c
>   patch -p1 < 0001-usb-typec-tcpm-reset-internal-port-states-on-soft-re.patch
>   git diff # incorrect backport that was actually sent out
> 
>   The second example is even worse, as there the incorrect backport was
>   actually released.
> 
> Just using 'git cherry-pick', as contributors are already being asked to
> do in the FAILED emails themselves, avoids these problems.
> 
> Can this please be fixed?  This outdated cherry-pick process is reducing
> the quality of the stable releases.

Any update on this from the stable maintainers?  Requiring resends for
clean cherry-picks is a waste of time for everyone, among other issues I
mentioned.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[Eric Biggers]

On Wed, Oct 28, 2026 at 11:20:14AM -0700, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 09:48:36AM -0700, Eric Biggers wrote:
> > On Wed, Oct 21, 2026 at 08:48:08AM -0700, Eric Biggers wrote:
> > > [+Cc linux-crypto@vger.kernel.org]
> > > 
> > > On Wed, Oct 21, 2026 at 04:40:37PM +0200, gregkh@linuxfoundation.org wrote:
> > > > 
> > > > The patch below does not apply to the 6.12-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>.
> > > 
> > > It's a clean cherry-pick, as git detects the rename of
> > > poly1305-armv8.pl.  So there should be no need to require this to be
> > > resent.  Also, missing Cc to linux-crypto.
> > > 
> > > Same for 6.12, 6.6, 6.1, 5.15, and 5.10.
> > 
> > As I've said before, the reason this keeps happening is that Greg's
> > stable scripts perform a cherry-pick by first formatting the commit as a
> > patch file with the default 3 lines of context, then applying it with
> > 'patch' using the default fuzz of 2.
> > 
> > (The second step seems to occur in the 'apply_it' script, which isn't
> > public.  But based on the observed behavior, it must be what it does.)
> > 
> > This process is buggy compared to simply using 'git cherry-pick':
> > 
> > - It has no rename detection.  Any file rename, like what happened for
> >   this commit where poly1305-armv8.pl is in different locations in
> >   different branches, results in FAILED.  This happens regularly.
> > 
> > - Incorrect backports due to only *one* line of context being
> >   considered (since 3 - 2 = 1).  For examples of this, see
> >   https://lore.kernel.org/all/20260512173933.811124271@linuxfoundation.org/
> >   and
> >   https://lore.kernel.org/all/20260515154719.961677988@linuxfoundation.org/
> > 
> >   This is easily reproducible.  For example for the first one:
> > 
> >   git checkout -d v6.12.87
> >   git cherry-pick 2909f0d4994fb4306bf116df5ccee797791fce2c
> >   git show # correct backport
> > 
> >   git checkout -d v6.12.87
> >   git format-patch -1 --no-base 2909f0d4994fb4306bf116df5ccee797791fce2c
> >   patch -p1 < 0001-usb-typec-tcpm-reset-internal-port-states-on-soft-re.patch
> >   git diff # incorrect backport that was actually sent out
> > 
> >   The second example is even worse, as there the incorrect backport was
> >   actually released.
> > 
> > Just using 'git cherry-pick', as contributors are already being asked to
> > do in the FAILED emails themselves, avoids these problems.
> > 
> > Can this please be fixed?  This outdated cherry-pick process is reducing
> > the quality of the stable releases.
> 
> Any update on this from the stable maintainers?  Requiring resends for
> clean cherry-picks is a waste of time for everyone, among other issues I
> mentioned.

Seems there's no choice but to work around the process by sending out
clean cherry picks, so I've done so.

I guess I need to start using lei as well to get stable emails for
subsystems I'm interested in as well, to work around the apparent
deprecation of the subsystem mailing lists.

As for Greg/Sasha creating incorrect backports by using 'patch' instead
of 'git cherry-pick', I guess the workaround, at least for my own
commits that I might have time to check this for, is that I need to redo
every clean cherry-pick myself and verify that what was sent by
Greg/Sasha actually matches, as Greg/Sasha's process may instead patch a
different place in the file that has the same 1 line of context.

Just seems really time consuming for everyone involved to be working
around these unnecessary issues.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[Greg KH]

On Wed, Oct 21, 2026 at 09:48:36AM -0700, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 08:48:08AM -0700, Eric Biggers wrote:
> > [+Cc linux-crypto@vger.kernel.org]
> > 
> > On Wed, Oct 21, 2026 at 04:40:37PM +0200, gregkh@linuxfoundation.org wrote:
> > > 
> > > The patch below does not apply to the 6.12-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>.
> > 
> > It's a clean cherry-pick, as git detects the rename of
> > poly1305-armv8.pl.  So there should be no need to require this to be
> > resent.  Also, missing Cc to linux-crypto.
> > 
> > Same for 6.12, 6.6, 6.1, 5.15, and 5.10.
> 
> As I've said before, the reason this keeps happening is that Greg's
> stable scripts perform a cherry-pick by first formatting the commit as a
> patch file with the default 3 lines of context, then applying it with
> 'patch' using the default fuzz of 2.
> 
> (The second step seems to occur in the 'apply_it' script, which isn't
> public.  But based on the observed behavior, it must be what it does.)

That script has been public for decades:
	https://github.com/gregkh/gregkh-linux/blob/master/stable/apply_it

> This process is buggy compared to simply using 'git cherry-pick':

Agreed, see my previous message, we don't use git cherry-pick for this
workflow, sorry.

thanks,

greg k-h

Re: FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[Greg KH]

On Wed, Oct 21, 2026 at 08:48:06AM -0700, Eric Biggers wrote:
> [+Cc linux-crypto@vger.kernel.org]
> 
> On Wed, Oct 21, 2026 at 04:40:37PM +0200, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 6.12-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>.
> 
> It's a clean cherry-pick, as git detects the rename of
> poly1305-armv8.pl.  So there should be no need to require this to be
> resent.  Also, missing Cc to linux-crypto.

For both of these, we have explained in the past why that is the case.

For the cherry-pick issue, we use quilt for the stable trees because it
can handle adding/moving/deleting things in any order, like is required
here.  Using a git tree does not.  So cherry-pick is not part of our
backport process because it's just not possible.

To make it possible, at each commit we would have to keep a local copy
of the current patches in a git tree, and then generate the new commit
from that, pull it out of that tree, apply it to the quilt tree, and
then go and regenerate the git tree (if needed).  In short, a mess and
would slow us down even more.

So yes, renames for "simple" things are a pain at times, it's just part
of the process.  Luckily Sasha's bot catch them quickly and provide a
backport easily in a day or so, so if you want, just rely on that.

For cc: the mailing list, no, we don't do that as it would make things
SO much noiser, and for some patches, a total mess.  We cc: everyone
involved in the original patch based on the info in the commit itself.
That's a policy decision we aren't going to change at this point in time
and attempting to add it for only one subsystem like you have asked for
here is going to be a mess.

If you care about these types of failures, just set up a lei filter to
catch them as we post these failures in public, that way no additional
mail needs to be sent.

thanks,

greg k-h