diff options
| author | Mohamad Raizudeen <raizudeen.kerneldev@gmail.com> | 2026-09-26 20:29:03 +0530 |
|---|---|---|
| committer | Eric Biggers <ebiggers@kernel.org> | 2026-09-29 15:28:42 -0700 |
| commit | 226154ea87952ad7141ce2dcf52a6c2edd71b8fe (patch) | |
| tree | c4cbdbaf1e41b2933121fd0622133f54bda8a5cb /tools/lib/python/kdoc | |
| parent | 93f51579e7df248780214094418f205253383cc5 (diff) | |
| download | linux-next-226154ea87952ad7141ce2dcf52a6c2edd71b8fe.tar.gz linux-next-226154ea87952ad7141ce2dcf52a6c2edd71b8fe.zip | |
crypto: x86/aes-gcm - fix always true check for last AAD segment
In gcm_process_assoc(), a segment that is not the last one must have its
length rounded down to a multiple of 16 bytes, as required by the
assembly. The check for a non-last segment is `if (unlikely(assoclen))
/* Not the last segment yet? */` where assoclen is the number of AAD
bytes remaining after the current segment.
Since the conversion to the new scatterwalk API, assoclen is decremented
at the end of the loop body rather than the beginning, so it still
includes the current segment when the check executes, making the check
always true.
As a result the last segment was rounded down as well, causing some
avoidable extra work: an additional memcpy into the temporary buffer and
an additional call into the assembly after the loop. The GCM
authentication tag is unaffected either way, so the self-tests pass and
this went unnoticed. It is purely an efficiency issue rather than a
correctness one.
Fix this by moving the assoclen decrement back to the beginning of the
loop body.
Fixes: e9787deff49e ("crypto: x86/aes-gcm - use the new scatterwalk functions")
Cc: stable@vger.kernel.org
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
Link: https://patch.msgid.link/20260926145903.6061-1-raizudeen.kerneldev@gmail.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc')
0 files changed, 0 insertions, 0 deletions
