[PATCH AUTOSEL 6.18-6.1] crypto: keembay - add missing MODULE_DEVICE_TABLE()

[PATCH AUTOSEL 6.18-6.1] crypto: keembay - add missing MODULE_DEVICE_TABLE()

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit b73b71df4cb4ca241165ad31218c82dfe489147c ]

The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().

Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.

This is a source-level fix.  It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Local tree

This checkout is **v7.3-rc4** (`7.3.0-rc4`, `git describe`:
`v7.3-rc4-27-gf0100363d8c37`). The candidate is `b73b71df4cb4c`
(`crypto: keembay - add missing MODULE_DEVICE_TABLE()`). The Keem Bay
OCS ECC driver is present here. The verdict is for this tree’s lineage:
does this one-line autoload fix meet stable rules given that the driver
and the missing alias exist in this code.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**
Record: **[crypto: keembay] [add] [missing MODULE_DEVICE_TABLE() for OF
module autoload]**

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- No `Fixes:` tag (expected for this review)
- No `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, `Link:`,
  or `Cc: stable@vger.kernel.org`
- `Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>` (author)
- `Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>` (crypto
  maintainer; applied the patch)
- Ignore pipeline `Signed-off-by: Sasha Levin` / `[Upstream commit ...]`
  if present; they are not in this git object

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** `kmb_ocs_ecc_of_match[]` is wired to `.of_match_table` but
  not exported with `MODULE_DEVICE_TABLE(of, ...)`.
- **Symptom:** OF `modules.alias` entries are not generated, so
  udev/kmod will not autoload `keembay-ocs-ecc` from the DT compatible
  `intel,keembay-ocs-ecc`.
- **Version info:** none in the message.
- **Root cause:** missing module-alias publication for an existing match
  table. Author states this is a source-level finding, not a live
  hardware repro.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not disguised cleanup. It is an explicit autoload/enablement
fix. Same class as adding a device ID for modular builds.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/crypto/intel/keembay/keembay-ocs-ecc.c` — **+1 / −0**
- Function/scope: file-scope `kmb_ocs_ecc_of_match[]` (no function body
  change)
- Classification: **single-file surgical fix**

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- **Before:** match table exists and is used for bind-time matching if
  the driver is already loaded (built-in, or loaded some other way).
- **After:** `modpost`/`file2alias` also emit `of:` aliases from that
  table, so DT device appearance can load the module.
- Path affected: **module autoload / init**, not the probe runtime path.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record:
- Category: **hardware enablement / missing device-ID publication** (OF
  module aliases)
- Mechanism: without `MODULE_DEVICE_TABLE`, `scripts/mod/file2alias.c`
  does not emit aliases for `intel,keembay-ocs-ecc`. Built-in still
  binds; **`CONFIG_CRYPTO_DEV_KEEMBAY_OCS_ECC=m` does not autoload from
  DT**.
- Confirmed in `include/linux/module.h`: `MODULE_DEVICE_TABLE` creates
  the alias symbol `file2alias` scans.

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: one standard macro next to the existing table,
  matching sibling Keem Bay drivers (AES, HCU).
- Minimal; no locking, no API, no data-structure change.
- Regression risk: **very low**. Macro is a no-op for built-in; for
  modules it only adds aliases.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Match table introduced in **`c9f608c380090`** (“crypto: keembay-ocs-
  ecc - Add Keem Bay OCS ECC Driver”, Prabhjot Khurana, 2021-10-20).
- `git merge-base --is-ancestor c9f608c380090 v5.16` succeeded → first
  appeared in **v5.16**.
- Bug: table never had `MODULE_DEVICE_TABLE` until `b73b71df4cb4c`
  (2026-07-13). Long-lived.

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. Introducer is `c9f608c380090`, ancestor of
HEAD.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record:
- `86c85d6657e47` (2024-08-24): **“crypto: keembay - fix module
  autoloading”** — same fix for HCU (`MODULE_DEVICE_TABLE(of,
  kmb_ocs_hcu_of_match)`).
- `0a94091e29f91`: same publication for OCS AES/SM4.
- `fbf31dd599875` (v6.4-rc1): moved driver to
  `drivers/crypto/intel/keembay/`.
- Standalone one-liner; not patch N/M.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Pengpeng Hou is a regular contributor of
missing-`MODULE_DEVICE_TABLE` and validation fixes (ixp4xx crypto,
several RTC/vdpa/watchdog/hwmon drivers). Not the Keem Bay maintainer.
Crypto maintainer Herbert Xu applied it.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: None. Uses existing `of_device_id` table and
`MODULE_DEVICE_TABLE`. Applies standalone on this tree.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c b73b71df4cb4c` →
  https://patch.msgid.link/20260704124609.16628-1-pengpeng@iscas.ac.cn
- `b4 dig -a`: **v1 only**; committed version is that v1.
- Thread (mbox): Herbert Xu: **“Patch applied. Thanks.”** No NAK, no
  requested changes, no `Cc: stable` from reviewers.
- Direct lore HTTP fetch returned 403/Anubis; discussion recovered via
  `b4 dig -m`.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record (`b4 dig -w`): To/Cc included Prabhjot Khurana, Mark Gross,
**Herbert Xu**, David S. Miller, `linux-crypto@`, `linux-kernel@`.
Maintainer applied it. No extra Reviewed-by on the commit.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No Reported-by / bugzilla / syzbot. Author calls it a source-
level finding. No user crash report found.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: Same-day sibling `1e5004d5a3a80` (“crypto: ixp4xx - add missing
MODULE_DEVICE_TABLE()”), same commit-message template. Systematic scan,
still a real missing-alias bug.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: **UNVERIFIED** for lore.kernel.org/stable (Anubis bot-wall). No
in-tree evidence this was rejected for stable.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: IDENTIFY KEY FUNCTIONS**
Record: No function body changed. Touches `kmb_ocs_ecc_of_match[]` used
by `kmb_ocs_ecc_driver` (`module_platform_driver`).

**Step 5.2: TRACE CALLERS**
Record: `kmb_ocs_ecc_probe()` is the platform `.probe`. Called by the
platform bus when a device matches `intel,keembay-ocs-ecc`. Autoload is
the missing step before probe for `=m`.

**Step 5.3: TRACE CALLEES**
Record: Probe ioremaps, requests IRQ, starts `crypto_engine`, registers
ECDH P-256/P-384. Unchanged.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Reachable when `ARCH_KEEMBAY` (or `COMPILE_TEST`) and
`CRYPTO_DEV_KEEMBAY_OCS_ECC=m`, and DT has `intel,keembay-ocs-ecc`.
Kconfig: “Say Y or M if you are compiling for the Intel Keem Bay SoC.”
In-tree DTS (`arch/arm64/boot/dts/intel/`) has **no** `ocs-ecc` node
(only the binding example). Hardware is still a real SoC (`ARCH_KEEMBAY`
in `arch/arm64/Kconfig.platforms`). Userspace does not trigger this via
a generic syscall; DT device + modular driver does.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: Same omission later fixed in HCU (`86c85d6657e47`) and AES
(`0a94091e29f91`). This is the remaining ECC sibling.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: **Yes.** File and `kmb_ocs_ecc_of_match[]` are here. Pre-fix
parent of `b73b71df4cb4c` had the table and `.of_match_table` assignment
with no `MODULE_DEVICE_TABLE`. Introduced v5.16; this tree is 7.3-rc4.
`git merge-base --is-ancestor b73b71df4cb4c HEAD` is true (landed by
7.3-rc1). That does not make the fix unworthy of stable; it confirms the
driver/bug lived in this lineage.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean apply** on this tree (already applied as +1 line). Older
stables before `fbf31dd599875` use `drivers/crypto/keembay/`; that is a
path tweak only, not a semantic dependency for this checkout.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: HCU and AES already publish OF aliases. No alternate ECC
autoload fix besides this commit. Driver also has
`MODULE_ALIAS_CRYPTO("ecdh-nist-p256")` etc., which can load the module
on crypto-API request, **not** on DT device appearance.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: `drivers/crypto/intel/keembay/` — SoC crypto accelerator.
**PERIPHERAL** (Keem Bay / Movidius only), but an existing in-tree
driver, not staging.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Moderate churn (crypto_engine API, remove-callback, directory
move). Match table itself unchanged since 2021 except this alias line.
Maintainer: Prabhjot Khurana; applied by Herbert Xu.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: **platform-specific / config-specific** —
`CRYPTO_DEV_KEEMBAY_OCS_ECC=m` on Keem Bay with a DT node for OCS ECC.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Boot/enumeration when the OF device is created and the driver is
a module. Not a race. Unprivileged users do not trigger it directly.
Common on that SoC if the node exists; rare globally.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Hardware crypto module does not autoload from DT; ECDH offload
missing until manual `modprobe` or a crypto-alias load. Not
panic/UAF/corruption. **MEDIUM** functional/enablement (stable’s “device
ID” class).

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit:** modular Keem Bay ECC actually binds at device discovery.
  Same class as device-ID additions.
- **Risk:** very low (one macro).
- **Ratio:** favorable.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real modular autoload bug: OF match table present, aliases not
  published.
- Official stable rules: *“fix a real bug that bothers people **or just
  add a device ID**.”* This is publishing an existing OF ID for modules.
- User-prompt exception: new/missing device IDs and hardware enablement
  on an existing driver.
- +1 line, obviously correct, maintainer-applied, v1 unchanged.
- Same fix already used on sibling HCU/AES drivers.
- Driver has been in this lineage since v5.16; no missing prerequisites
  in this tree.

AGAINST:
- No user/syzbot report; author says source-level only.
- Niche SoC; no in-tree DTS node for this compatible.
- `MODULE_ALIAS_CRYPTO` can still load the module on algorithm request.
- Not a crash, leak, or security bug.

UNRESOLVED:
- Stable-list discussion (lore blocked).
- Whether out-of-tree Keem Bay DTs include `intel,keembay-ocs-ecc`.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — standard macro; applied by
   Herbert Xu.
2. Fixes a real bug that affects users? **PASS** — modular OF autoload
   does not work; device-ID equivalent.
3. Important issue? **PASS** under the device-ID / hardware-enablement
   exception (not a panic).
4. Small and contained? **PASS** — 1 line, 1 file.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS** — file and table exist; applies
   as a single insertion.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: **Device ID / module-alias publication for an existing driver.**

**Step 9.4: MAKE YOUR DECISION**
This is a one-line, obviously correct enablement fix: the driver already
matches `intel,keembay-ocs-ecc`, but modular builds never advertised
that ID to userspace. That is the same class of change stable already
takes for PCI/USB/OF IDs. Risk is negligible. This 7.3-rc4 tree contains
the driver and the historical bug; the patch is appropriate to carry on
this lineage’s stable trees.

### What the commit solves
Without `MODULE_DEVICE_TABLE(of, kmb_ocs_ecc_of_match)`, `modpost` does
not emit OF aliases, so a modular `keembay-ocs-ecc` will not autoload
when the DT device appears. Built-in still works. The fix only publishes
the existing match table.

### Risk vs benefit
Benefit is hardware actually probing on modular Keem Bay systems. Risk
is a compile-time alias with no runtime logic change.

### Concerns
Niche platform; no crash report. That does not disqualify a device-ID-
class one-liner. No functional dependencies.

Verification:
- [Phase 1] `git log -1 --format='%B' b73b71df4cb4c`: tags as listed; no
  Fixes/Reported-by/Cc: stable
- [Phase 2] `git show b73b71df4cb4c`: +1 line `MODULE_DEVICE_TABLE(of,
  kmb_ocs_ecc_of_match)`
- [Phase 2] `include/linux/module.h` and `scripts/mod/file2alias.c`:
  alias generation confirmed
- [Phase 3] `git blame` on match table: introducer `c9f608c380090`; `git
  merge-base --is-ancestor c9f608c380090 v5.16` succeeded
- [Phase 3] Sibling fixes `86c85d6657e47` (HCU) and `0a94091e29f91`
  (AES) confirmed
- [Phase 4] `b4 dig -c/-a/-w/-m`: v1 lore URL; Herbert “Patch applied.
  Thanks.”; crypto list + original Intel authors
- [Phase 4] lore HTTP: 403/Anubis — UNVERIFIED via WebFetch/curl
- [Phase 5] Probe at `kmb_ocs_ecc_probe`; grep found no in-tree DTS
  using `intel,keembay-ocs-ecc`
- [Phase 6] `git describe HEAD` → v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion` → 7.3.0-rc4; pre-fix parent lacks the macro; driver
  present
- [Phase 6] `git merge-base --is-ancestor b73b71df4cb4c HEAD` succeeded
- [Phase 7] Kconfig `CRYPTO_DEV_KEEMBAY_OCS_ECC` depends on
  `ARCH_KEEMBAY || COMPILE_TEST`
- [Phase 8] Failure mode: missing module autoload, not oops
- UNVERIFIED: stable@ mailing-list discussion; live hardware
  reproduction (author did not claim one)

**YES**

 drivers/crypto/intel/keembay/keembay-ocs-ecc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/intel/keembay/keembay-ocs-ecc.c b/drivers/crypto/intel/keembay/keembay-ocs-ecc.c
index 59308926399d0..f31b5ae73f664 100644
--- a/drivers/crypto/intel/keembay/keembay-ocs-ecc.c
+++ b/drivers/crypto/intel/keembay/keembay-ocs-ecc.c
@@ -987,6 +987,7 @@ static const struct of_device_id kmb_ocs_ecc_of_match[] = {
 	},
 	{}
 };
+MODULE_DEVICE_TABLE(of, kmb_ocs_ecc_of_match);
 
 /* The OCS driver is a platform device. */
 static struct platform_driver kmb_ocs_ecc_driver = {
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.6] crypto: keembay - use crypto_memneq() to compare GCM AEAD tags

[Sasha Levin]

From: "David C.C.M. Gall" <david.ccm.gall@googlemail.com>

[ Upstream commit 353b3a85136f2a0cf3e872acf8ad6c1dec0b7a8e ]

Use crypto_memneq() for constant-time comparison.

The GCM path in keembay-ocs-aes-core.c verifes the received
authentication tag with memcmp(), which returns early on the first
mismatched byte. This leaks valid-prefix length and allows for valid
tag forgery which violates the INT-CTXT guarantee of AEAD.

Assisted-by: gregkh_clanker_t1000
Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is a 3-line constant-time tag compare for Keem Bay GCM decrypt. The
local tree is **6.12.111** (`pending-6.12`, `p-6.12-3-gc504cf0baa3d8`).
The buggy `memcmp()` is present; the candidate is not.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: `[crypto: keembay] [use] [replace memcmp with crypto_memneq for
GCM AEAD tag compare]`

- Subsystem: `crypto: keembay` (Intel Keem Bay OCS AES driver)
- Action verb: **use** (the body is a security fix: constant-time
  compare)
- Intent: stop early-exit `memcmp()` from leaking valid-tag prefix
  length

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- **Fixes:** none (expected)
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none
- **Acked-by:** none
- **Link:** none
- **Cc: stable:** none (expected)
- **Assisted-by:** gregkh_clanker_t1000
- **Signed-off-by:** David C.C.M. Gall `<david.ccm.gall@googlemail.com>`
  (author)
- **Signed-off-by:** Herbert Xu `<herbert@gondor.apana.org.au>` (crypto
  maintainer, applied it)

SHA: `353b3a85136f2a0cf3e872acf8ad6c1dec0b7a8e`
AuthorDate: 2026-08-07. No syzbot, no multi-reporter pattern.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** GCM decrypt checks the received auth tag with `memcmp()`,
  which returns on the first mismatch.
- **Symptom/failure mode:** timing leak of matching-prefix length; that
  leak can be used to forge a valid tag and break AEAD **INT-CTXT**
  (integrity of ciphertext).
- **Version info:** none in the message.
- **Root cause (author):** non-constant-time compare of `in_tag` vs
  `out_tag`.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: Not hidden. It is an explicit crypto security fix (timing side
channel / AEAD integrity), even without the word “fix” in the subject.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**

Record:
- File: `drivers/crypto/intel/keembay/keembay-ocs-aes-core.c` (+2 / −1)
- Functions: `#include` plus `kmb_ocs_aead_run()`
- Scope: single-file surgical fix

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Include hunk:** adds `#include <crypto/utils.h>` (declares
  `crypto_memneq()`).
- **Compare hunk (GCM decrypt only):** after `ocs_aes_gcm_op()`, if
  `rctx->instruction == OCS_DECRYPT`:
  - Before: `rc = memcmp(rctx->in_tag, rctx->out_tag, tag_size) ?
    -EBADMSG : 0;`
  - After: `rc = crypto_memneq(rctx->in_tag, rctx->out_tag, tag_size) ?
    -EBADMSG : 0;`
- Encrypt path, CCM path, and DMA cleanup are unchanged.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record:
- **Category:** cryptographic timing / logic correctness (not UAF, leak,
  race).
- **Mechanism:** `memcmp()` is not constant-time. `crypto_memneq()` is
  (`lib/crypto/memneq.c`, `noinline`). Both treat 0 as equal, so
  `-EBADMSG` vs `0` is unchanged; only timing changes.

CCM still uses `memcmp()` in `ocs-aes.c:ccm_compare_tag_to_yr()`; that
is a sibling patch (`ff2ac77a034e0`), not a dependency of this one.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- Obviously correct: one-for-one substitution with the API crypto
  drivers already use for MAC/tag compares (`talitos`, `nx`, `atmel-
  aes`, `stm32-cryp`, etc. in this tree).
- Minimal; no API/data-structure change.
- Regression risk: very low. Return mapping matches. `crypto_memneq` is
  slightly slower by design (no early exit); that is the fix.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- Introduced in `88574332451380f4b51f6ca88ab9810e714bfb9b` (“crypto:
  keembay - Add support for Keem Bay OCS AES/SM4”), 2020-12-11, Mike
  Healy.
- Original hunk: `rc = memcmp(rctx->in_tag, rctx->out_tag, tag_size) ?`
- Present since **v5.11** (`git merge-base --is-ancestor` vs `v5.10`
  fails, vs `v5.11` succeeds). Long-standing, not recent.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: No `Fixes:` tag. Functionally this fixes the original driver
commit `8857433245138`, which **is** an ancestor of this 6.12 HEAD.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record (this tree, that file): OF alias, IRQ completion init, AEAD
unregister count, platform-remove conversion, crypto_engine_op,
prepare/unprepare removal, path move. None of those change the GCM
`memcmp`. Standalone vs the CCM sibling (patch 2/2, different file).

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: David C.C.M. Gall is not the keembay maintainer. On `crypto-
next` the same author has a batch of `crypto_memneq` conversions:
keembay GCM, keembay CCM, sa2ul, octeontx, octeontx2, ccree. Crypto
maintainer Herbert Xu applied this one.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record:
- Needs `crypto_memneq` / `crypto/utils.h` — both exist here
  (`include/crypto/utils.h`, `lib/crypto/memneq.c`).
- `crypto/internal/aead.h` already includes `crypto/algapi.h` →
  `crypto/utils.h`, so the extra include is redundant but matches
  mainline and is harmless.
- No prerequisite series beyond this one hunk. `git apply --check` of
  `353b3a85136f2` succeeded on this tree.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- `b4 dig -c 353b3a85136f2`:
  https://patch.msgid.link/anYEQOzunX0Lm3N1@david.gall
- `b4 dig -a`: single revision, **v1** `[PATCH 1/2]`. No v2/v3.
- Saved thread `/tmp/keembay-gcm-memneq.mbox` (2 messages).
- Herbert Xu (2026-08-15): “All applied. Thanks.” No NAK, no review
  nits, **no Cc: stable**.
- Direct lore WebFetch returned 403; discussion taken from the b4 mbox.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record (`b4 dig -w`): To/Cc Herbert Xu, David S. Miller, linux-crypto,
linux-kernel, gregkh@linuxfoundation.org. Subsystem maintainer was
included and applied the patch. No Reviewed-by tags.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: No Reported-by, no syzbot, no bugzilla. Issue is from code
review / known `memcmp`-vs-MAC pattern, not a user crash report.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: Series is 2/2. Patch 2 is CCM `memcmp` in `ocs-aes.c`.
Independent of this GCM change. Same pattern as historical stable-bound
fixes:
- `79960943fdc11` crypto: talitos - Fix timing leak in ESP ICV
  verification (`Cc: stable`)
- `cb8affb55c7e6` crypto: nx - Fix timing leak in GCM and CCM decryption
  (`Cc: stable`)

Both are already ancestors of this 6.12 HEAD.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: lore.kernel.org/stable WebFetch returned 403. **UNVERIFIED**
whether anyone already asked for this on stable@. Original crypto thread
has no stable nomination.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

No semcode MCP tools. Used grep + file reads.

**Step 5.1: IDENTIFY KEY FUNCTIONS**

Record: `kmb_ocs_aead_run()` (only runtime change).

**Step 5.2: TRACE CALLERS**

Record:
- `kmb_ocs_aes_aead_do_one_request()` → `kmb_ocs_aead_run()`
- Engine op `.do_one_request` for `gcm(aes)`, `ccm(aes)`, `gcm(sm4)`,
  `ccm(sm4)`
- Encrypt/decrypt entry: `kmb_ocs_aes_gcm_decrypt` /
  `kmb_ocs_sm4_gcm_decrypt` → `kmb_ocs_aead_common()` →
  `crypto_transfer_aead_request_to_engine()`
- CCM returns before the changed lines; only GCM decrypt hits
  `memcmp`/`crypto_memneq`.

**Step 5.3: TRACE CALLEES**

Record: After `ocs_aes_gcm_op()`, compare tags, then
`kmb_ocs_aead_dma_cleanup()`. No extra alloc/lock from this hunk.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record:
- Registered as `gcm(aes)` / `gcm(sm4)` with priority 350.
- `CRYPTO_ALG_KERN_DRIVER_ONLY` means HW accel not via a userspace ISA;
  it is **not** `CRYPTO_ALG_INTERNAL`. `af_alg.c` allows that flag, so
  AF_ALG can still select the driver.
- Also used by in-kernel AEAD (IPsec, TLS, etc.) when this HW is chosen.
- Path is reachable whenever Keem Bay OCS AES is enabled and GCM decrypt
  runs.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Remaining `memcmp` in this driver is CCM (`ocs-aes.c:1285`),
sibling commit. Other HW AEAD drivers in this tree already use
`crypto_memneq`.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: **Yes.** `drivers/crypto/intel/keembay/keembay-ocs-aes-
core.c:922` still has `memcmp(rctx->in_tag, rctx->out_tag, tag_size)`.
Introduced v5.11; present in 6.12. Candidate is **not** an ancestor of
HEAD (`git merge-base --is-ancestor 353b3a85136f2 HEAD` failed).
Kconfig: `CRYPTO_DEV_KEEMBAY_OCS_AES_SM4` depends on `ARCH_KEEMBAY ||
COMPILE_TEST`. `ARCH_KEEMBAY` exists (`arch/arm64/Kconfig.platforms`).

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **Clean apply.** Surrounding GCM decrypt block matches the
patch. `crypto/utils.h` exists.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: No keembay `crypto_memneq` commit in this tree. GCM `memcmp`
still there.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record:
- Subsystem: `drivers/crypto/intel/keembay` (platform crypto
  accelerator)
- Criticality: **PERIPHERAL** for most 6.12 users (Keem Bay / Movidius
  SoC only), but the bug is a real AEAD integrity issue for those users.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Mature driver (2020). Recent 6.12 commits are small
correctness/build items, not a rewrite of GCM tag handling.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: Driver/platform-specific:
`CONFIG_CRYPTO_DEV_KEEMBAY_OCS_AES_SM4` on Keem Bay, GCM(AES/SM4)
decrypt on that HW.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: Every successful GCM decrypt on this engine compares tags.
Trigger is ordinary decrypt, not a rare error path. Unprivileged users
can hit it via AF_ALG or via kernel users of `gcm(aes)`. Practical
exploitation needs timing measurement (local is realistic; remote is
harder). The integrity guarantee is still broken even if remote exploit
is hard.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record:
- Failure: timing leak of valid-tag prefix → tag forgery → **INT-CTXT**
  failure (forged ciphertext accepted).
- Severity: **HIGH** (crypto/security). Not a panic/deadlock. Same class
  historically sent to stable (talitos/nx).

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit:** restores AEAD integrity for Keem Bay GCM users on 6.12
  LTS.
- **Risk:** very low (3 lines, equivalent control flow, well-used
  helper).
- **Ratio:** benefit > risk. Niche HW lowers population, not the
  correctness of backporting a tiny security fix.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

**FOR backporting:**
- Real AEAD security bug (non-constant-time tag compare / INT-CTXT).
- Buggy `memcmp` is in this 6.12 tree since the v5.11 driver.
- 3-line, obviously correct, applies cleanly.
- `crypto_memneq` already in tree; same pattern used by other drivers
  here.
- Crypto maintainer applied it; historical sibling timing-leak fixes
  were stable-bound.
- No new API/feature.

**AGAINST:**
- Peripheral SoC (`ARCH_KEEMBAY`), small user base.
- No user/syzbot report, no CVE, no `Cc: stable`.
- AI-assisted; no Tested-by/Reviewed-by besides maintainer apply.
- CCM `memcmp` remains until the sibling patch (this GCM fix is still
  complete on its own).

**UNRESOLVED:**
- Stable@ search 403 (whether anyone already nominated this).
- No public measurement of exploitability on this SoC (generic
  `memcmp`-MAC analysis still holds).

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — one helper swap; maintainer
   applied; helper is the standard MAC compare. No extra runtime test
   tags.
2. Fixes a real bug that affects users? **PASS** — GCM decrypt on this
   HW uses `memcmp` today.
3. Important issue? **PASS** — AEAD integrity / timing side channel
   (HIGH), not a crash.
4. Small and contained? **PASS** — 3 lines, one file, one function.
5. No new features or APIs? **PASS**
6. Can apply to the local tree? **PASS** — `git apply --check`
   succeeded.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: Not a device-ID/quirk/DT/build/docs exception. Qualifies as a
small security correctness fix.

**Step 9.4: MAKE YOUR DECISION**

The patch closes a real INT-CTXT hole with a 3-line, clean apply on this
6.12 tree. Niche hardware is not a reason to leave a known AEAD tag-
timing bug in LTS.

### What it solves for this tree
Keem Bay OCS GCM decrypt still uses early-exit `memcmp` on the auth tag.
That leaks how much of the tag matched and can be used to forge tags.
Replacing it with `crypto_memneq()` makes the compare constant-time
without changing success/failure semantics.

### Risk vs benefit
Benefit is restoring AEAD integrity for that decrypt path. Risk is
negligible: same branch structure, established helper, no locking or API
change.

---

Verification:
- [Phase 1] Parsed tags: Assisted-by gregkh_clanker_t1000; SOBs Gall +
  Herbert Xu; no Fixes/Reported-by/Cc:stable
- [Phase 1] SHA `353b3a85136f2a0cf3e872acf8ad6c1dec0b7a8e` on crypto-
  next; not ancestor of HEAD
- [Phase 2] Diff: +`crypto/utils.h`, `memcmp` → `crypto_memneq` in
  `kmb_ocs_aead_run()` GCM decrypt
- [Phase 2] Confirmed remaining CCM `memcmp` in `ocs-aes.c:1285` is
  sibling `ff2ac77a034e0`, not required here
- [Phase 2] `crypto_memneq` returns 0 equal / 1 unequal — same ternary
  as `memcmp`
- [Phase 3] `git blame`: memcmp from `8857433245138` (2020-12-11); in
  tree since v5.11
- [Phase 3] `git merge-base --is-ancestor 8857433245138 HEAD` succeeded
- [Phase 3] `git apply --check` of the candidate on this tree: success
- [Phase 3] Author’s related commits on crypto-next: keembay CCM, sa2ul,
  octeontx, ccree memneq conversions
- [Phase 4] `b4 dig -c`:
  https://patch.msgid.link/anYEQOzunX0Lm3N1@david.gall
- [Phase 4] `b4 dig -a`: v1 only, `[PATCH 1/2]`
- [Phase 4] `b4 dig -w`: Herbert Xu, davem, linux-crypto, gregkh CC’d
- [Phase 4] mbox: Herbert “All applied. Thanks.”; no NAK, no stable
  nomination
- [Phase 4] Direct lore/stable WebFetch: 403 — UNVERIFIED for stable@
  archive
- [Phase 4] Historical same-class fixes `79960943fdc11` (talitos) and
  `cb8affb55c7e6` (nx) have `Cc: stable` and are in this tree
- [Phase 5] Call chain: `kmb_ocs_aes_gcm_decrypt` →
  `kmb_ocs_aead_common` → engine → `kmb_ocs_aes_aead_do_one_request` →
  `kmb_ocs_aead_run`
- [Phase 5] Algs: `gcm(aes)`/`gcm(sm4)` priority 350; `KERN_DRIVER_ONLY`
  is not INTERNAL; AF_ALG allows that flag
- [Phase 6] `git describe HEAD`: `p-6.12-3-gc504cf0baa3d8`; `make
  kernelversion`: 6.12.111
- [Phase 6] Line 922 still `memcmp(...)` in this checkout
- [Phase 6] `include/crypto/utils.h` and `lib/crypto/memneq.c` present
- [Phase 7] Kconfig `depends on ARCH_KEEMBAY || COMPILE_TEST`;
  `ARCH_KEEMBAY` in arm64 Kconfig.platforms
- [Phase 8] Failure mode: AEAD tag timing leak / possible tag forgery,
  severity HIGH
- UNVERIFIED: exploit practicality on Keem Bay specifically; whether
  stable@ already discussed this commit

**YES**

 drivers/crypto/intel/keembay/keembay-ocs-aes-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/intel/keembay/keembay-ocs-aes-core.c b/drivers/crypto/intel/keembay/keembay-ocs-aes-core.c
index 419f88af1031b..c4fd5e1849cdf 100644
--- a/drivers/crypto/intel/keembay/keembay-ocs-aes-core.c
+++ b/drivers/crypto/intel/keembay/keembay-ocs-aes-core.c
@@ -11,6 +11,7 @@
 #include <crypto/internal/aead.h>
 #include <crypto/internal/skcipher.h>
 #include <crypto/scatterwalk.h>
+#include <crypto/utils.h>
 #include <linux/clk.h>
 #include <linux/completion.h>
 #include <linux/dma-mapping.h>
@@ -919,7 +920,7 @@ static int kmb_ocs_aead_run(struct aead_request *req)
 
 	/* For GCM decrypt, we have to compare in_tag with out_tag. */
 	if (rctx->instruction == OCS_DECRYPT) {
-		rc = memcmp(rctx->in_tag, rctx->out_tag, tag_size) ?
+		rc = crypto_memneq(rctx->in_tag, rctx->out_tag, tag_size) ?
 		     -EBADMSG : 0;
 		goto exit;
 	}
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.6] crypto: keembay - use crypto_memneq() to compare CCM AEAD tags

[Sasha Levin]

From: "David C.C.M. Gall" <david.ccm.gall@googlemail.com>

[ Upstream commit ff2ac77a034e03b64e2ba34f775097427dfa5547 ]

Use crypto_memneq() for constant-time comparison.

The CCM path in ocs-aes.c verifes the received authentication tag with
memcmp(), which returns early on the first mismatched byte. This leaks
valid-prefix length and allows for valid tag forgery which violates the
INT-CTXT guarantee of AEAD.

Assisted-by: gregkh_clanker_t1000
Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit message forensics

**Step 1.1 — Subject line**
Record: **[crypto/keembay] [use] replace `memcmp()` with
`crypto_memneq()` when comparing CCM AEAD tags.**
Subsystem prefix `crypto: keembay`. Verb is “use”, but the body is an
explicit security fix (constant-time compare).

**Step 1.2 — Tags**
Record:
- **Assisted-by:** gregkh_clanker_t1000
- **Signed-off-by:** David C.C.M. Gall `<david.ccm.gall@googlemail.com>`
  (author)
- **Signed-off-by:** Herbert Xu `<herbert@gondor.apana.org.au>` (crypto
  maintainer; applied the patch)
- **No Fixes:** tag (expected for this review)
- **No Cc: stable** (expected; not a negative)
- **No Reported-by / Tested-by / Reviewed-by / Acked-by / Link**

SHA on `origin/master` (Linus):
`ff2ac77a034e03b64e2ba34f775097427dfa5547`. Contained in `v7.3-rc1`.
Parent is the sibling GCM patch `353b3a85136f2`.

**Step 1.3 — Body**
Record:
- **Bug:** CCM decrypt in `ocs-aes.c` compares the authentication tag
  with `memcmp()`, which returns on the first mismatched byte.
- **Symptom / failure mode:** timing leak of the matching-prefix length;
  that can be used to forge a valid tag and **violates AEAD INT-CTXT**.
- **Root cause:** variable-time compare on a secret authentication tag.
- **Version info in message:** none. Bug is in the original driver
  (2020).

**Step 1.4 — Hidden bug fix?**
Record: **No disguise.** This is an explicit crypto-security fix, same
class as software `crypto/ccm.c` and other HW drivers that already use
`crypto_memneq()`.

---

## Phase 2: Diff analysis

**Step 2.1 — Inventory**
Record:
- File: `drivers/crypto/intel/keembay/ocs-aes.c` (**+2 / −1**)
- Functions: `ccm_compare_tag_to_yr()`; plus `#include <crypto/utils.h>`
- Scope: **single-file surgical fix**

**Step 2.2 — Code flow**
Record:
- **Before:** after CCM decrypt, hardware tag (`AES_T_MAC_*`) and `Yr`
  (`AES_MULTIPURPOSE2_*`) are compared with `memcmp()`; mismatch →
  `-EBADMSG`.
- **After:** same compare, same return values, but `crypto_memneq()`
  runs in constant time.
- Path: **normal CCM decrypt completion**, not an error/init-only path.

Verified in this tree at `ccm_compare_tag_to_yr()`:

```1285:1285:drivers/crypto/intel/keembay/ocs-aes.c
        return memcmp(tag, yr, tag_size_bytes) ? -EBADMSG : 0;
```

Called at the end of `ocs_aes_ccm_op()` on decrypt only.

`crypto_memneq()` in this tree returns 0 if equal, 1 otherwise
(`include/crypto/utils.h`), so the ternary is equivalent to `memcmp`’s
zero/non-zero sense.

**Step 2.3 — Bug mechanism**
Record: **[Memory safety / crypto side-channel]** — variable-time tag
compare. Fix is the standard constant-time helper. Not a
leak/UAF/race/NULL-deref.

**Step 2.4 — Fix quality**
Record: **Obviously correct and minimal.** Same pattern as
`crypto/ccm.c` (`crypto_memneq(authtag, odata, authsize)`) and HW
drivers (`talitos`, `nx`, `atmel-aes`, `stm32-cryp`, …).
Regression risk: **very low**. Semantics of success/fail are unchanged.
`CRYPTO` already `select CRYPTO_LIB_UTILS`, which builds
`lib/crypto/memneq.c`.

---

## Phase 3: Git history

**Step 3.1 — Blame**
Record: buggy `memcmp` introduced in
**`88574332451380f4b51f6ca88ab9810e714bfb9b`** (“crypto: keembay - Add
support for Keem Bay OCS AES/SM4”, Mike Healy, 2020-11-26). Present
since **v5.11**. `git merge-base --is-ancestor 8857433245138 HEAD` →
**yes**. Unchanged until this candidate.

**Step 3.2 — Fixes: tag**
Record: **N/A** (no Fixes: tag). Introducing commit is the original
driver add, and it **is** in this tree.

**Step 3.3 — File history in this tree**
Record: recent keembay work is DMA/probe/unregister fixes, not tag
compare. No prior memneq fix here.
Series: **patch 2/2**. Sibling **1/2** (`353b3a85136f2`) changes GCM
`memcmp` in `keembay-ocs-aes-core.c` only. **Not a prerequisite** for
this CCM hunk.

**Step 3.4 — Author**
Record: David C.C.M. Gall — two keembay memneq commits on
`origin/master` (GCM + CCM). Not the subsystem maintainer. **Herbert Xu
applied both.**

**Step 3.5 — Dependencies**
Record: needs `crypto_memneq` / `include/crypto/utils.h`. Header added
in `c616fb0cbae8a` (2023); **in this 6.12 tree**.
`include/crypto/algapi.h` already includes `crypto/utils.h`. **Applies
standalone.** `git apply --check` succeeded (hunks at offset −1).

Precedent already in this tree (explicitly Cc: stable):
- `79960943fdc11` crypto: talitos — timing leak in ESP ICV
- `cb8affb55c7e6` crypto: nx — timing leak in GCM/CCM decrypt

---

## Phase 4: Mailing list / external research

**Step 4.1 — Original discussion**
Record:
- `b4 dig -c ff2ac77a034e03b64e2ba34f775097427dfa5547` →
  https://patch.msgid.link/anYGKPaCNBgACGqK@david.gall
- Direct lore.kernel.org fetch returned **403** (Anubis). Thread also at
  https://lkml.iu.edu/hypermail/linux/kernel/2608.0/14033.html and
  https://lists.openwall.net/linux-kernel/2026/08/07/1640
- `b4 dig -a`: **v1 only** (no v2/v3). Committed diff matches v1.

**Step 4.2 — Recipients (`b4 dig -w`)**
Record: Herbert Xu, David S. Miller, linux-crypto, linux-kernel, gregkh.
**Crypto maintainer was To:’d.**

**Step 4.3 — Bug report**
Record: **no user/syzbot/bugzilla report.** Issue is from code review of
`memcmp` on AEAD tags.

**Step 4.4 — Series**
Record: **[PATCH 1/2]** GCM in `keembay-ocs-aes-core.c`; **[PATCH 2/2]**
this CCM change. Independent files. Herbert (2026-08-14): **“All
applied. Thanks.”** No NAK.

**Step 4.5 — Stable list**
Record: no evidence this patch was discussed on `stable@`. WebSearch on
lore.kernel.org/stable did not find a keembay/`crypto_memneq` thread.
**Unverified beyond that** because lore.kernel.org returned 403.

---

## Phase 5: Code semantic analysis

**Step 5.1 — Functions**
Record: `ccm_compare_tag_to_yr()` (modified). Callers/callees below from
this checkout.

**Step 5.2 — Callers**
Record:
- `ccm_compare_tag_to_yr()` ← `ocs_aes_ccm_op()` (decrypt only, line
  1398)
- `ocs_aes_ccm_op()` ← `kmb_ocs_aead_run()` when `rctx->mode ==
  OCS_MODE_CCM`
- `kmb_ocs_aead_run()` ← `kmb_ocs_aes_aead_do_one_request()` (crypto-
  engine `do_one_request`)
- Engine request queued from `kmb_ocs_aead_common()` ← CCM
  encrypt/decrypt for AES and SM4 (`ccm(aes)`, `ccm(sm4)`)

**Step 5.3 — Callees**
Record: `ioread32()` of tag/`Yr` registers, then compare. No alloc/lock
change.

**Step 5.4 — Reachability**
Record: reachable on **Keem Bay OCS CCM decrypt**
(`CONFIG_CRYPTO_DEV_KEEMBAY_OCS_AES_SM4`, `ARCH_KEEMBAY ||
COMPILE_TEST`). Algs are `CRYPTO_ALG_KERN_DRIVER_ONLY` (HW, not a CPU
ISA). Still used by in-kernel CCM consumers on that SoC (e.g. 802.11
CCMP-style CCM). Trigger is **every CCM decrypt**, not a rare error
path.

**Step 5.5 — Similar patterns**
Record: same driver still has GCM `memcmp` at `keembay-ocs-aes-
core.c:922` (sibling 1/2, not in this tree). Software CCM/GCM and many
HW drivers already use `crypto_memneq()`.

---

## Phase 6: This checkout (6.12.y)

**Step 6.1 — Buggy code present?**
Record: **Yes.** Local tree: **`pending-6.12` / 6.12.111**
(`p-6.12-3-gc504cf0baa3d8`).
`git merge-base --is-ancestor ff2ac77a034e0 HEAD` → **not in this
tree**.
`memcmp` still at `ocs-aes.c:1285`. Bug since v5.11.

**Step 6.2 — Backport difficulty**
Record: **clean apply** (`git apply --check`: both hunks succeed, offset
−1). `#include <crypto/utils.h>` exists here.

**Step 6.3 — Related fixes already here?**
Record: **No** keembay memneq fix. GCM sibling also absent. talitos/nx
timing-leak fixes **are** already here (same class, different drivers).

---

## Phase 7: Subsystem / maintainer

**Step 7.1**
Record: **crypto HW driver** (`drivers/crypto/intel/keembay/`).
Criticality: **PERIPHERAL** for population (Intel Movidius Keem Bay
only), but the bug is a **real AEAD security property break**.

**Step 7.2**
Record: modest activity (DMA/probe/unregister). Tag-compare code has
been **stable since 2020**.

---

## Phase 8: Impact and risk

**Step 8.1 — Who is affected**
Record: **platform-specific** — Keem Bay OCS AES/SM4 CCM decrypt
(`ccm(aes)` / `ccm(sm4)`).

**Step 8.2 — Trigger**
Record: every HW CCM decrypt. Timing-dependent. Unprivileged remote
trigger depends on what uses CCM on that SoC (e.g. wireless); not a
generic syscall UAF. **Security-relevant where CCM is used.**

**Step 8.3 — Failure mode**
Record: **timing leak → possible tag forgery / INT-CTXT break.**
Severity: **HIGH** (crypto integrity), not a panic. Incorrect
accept/reject is not the bug; **secret-dependent runtime** is.

**Step 8.4 — Risk vs benefit**
Record: **Benefit: HIGH for Keem Bay CCM users** (closes a well-known
AEAD side channel). **Risk: very low** (2 lines, equivalent control
flow, helper already in 6.12). Ratio favors backport.

---

## Phase 9: Synthesis

**Evidence FOR**
- Real AEAD security bug (INT-CTXT / tag-forgery via timing), not
  cleanup.
- Buggy `memcmp` is in **this** 6.12 tree since v5.11.
- 2-line, obviously correct swap to `crypto_memneq()`; same as in-tree
  `crypto/ccm.c` and Cc:stable talitos/nx fixes.
- `crypto_memneq` / `crypto/utils.h` already present; patch applies
  cleanly.
- Applied by crypto maintainer Herbert Xu; no NAK.
- Independent of series patch 1/2 (GCM file).

**Evidence AGAINST**
- Niche SoC (`ARCH_KEEMBAY`).
- No field/syzbot report.
- LLM-assisted tag in the message (does not change the correctness of
  the 2-line swap).
- Remaining GCM `memcmp` is a **separate** candidate, not a reason to
  skip CCM.

**Unresolved**
- Full lore.kernel.org thread body (403). Confirmed via b4 dig,
  lkml.iu.edu, openwall, and Herbert’s “All applied.”
- Practical exploitability over MMIO+DMA noise: **unverified**; kernel
  policy still requires constant-time tag compare.

**Stable rules**
1. Obviously correct and tested? **PASS** — semantic equivalent;
   maintainer applied; helper is the documented API.
2. Real user-facing bug? **PASS** — AEAD decrypt tag check.
3. Important (security)? **PASS** — INT-CTXT / timing side channel.
4. Small/contained? **PASS** — +2/−1, one function.
5. No new features/APIs? **PASS**.
6. Applies to this tree? **PASS** — `git apply --check` succeeded.

**Exception category:** none required; this is a small security fix.

This should be backported to **this** 6.12 tree: the bug is present, the
fix is the standard one-line compare change plus the existing header,
and it does not need the GCM sibling.

### What it solves for stable users
On Keem Bay, CCM decrypt used `memcmp()` on the authentication tag. That
can leak how many tag bytes matched and weakens AEAD integrity.
`crypto_memneq()` makes the compare constant-time. Same class of fix
already shipped in this tree for talitos and nx.

### Risk vs benefit
Benefit is closing a crypto integrity side channel on a path that runs
on every CCM decrypt. Risk is a two-line, behavior-preserving change
using an API already built via `CRYPTO` → `CRYPTO_LIB_UTILS`.

---

## Verification
- **[Phase 1]** Parsed tags from `git show ff2ac77a034e0` on
  origin/master: Assisted-by clanker; SOB Gall + Herbert Xu; no
  Fixes/Cc:stable/Reported-by.
- **[Phase 1]** `git describe HEAD` / Makefile: **6.12.111**, branch
  `pending-6.12`.
- **[Phase 2]** Diff: +`#include <crypto/utils.h>`, `memcmp` →
  `crypto_memneq` in `ccm_compare_tag_to_yr()`. `crypto_memneq` contract
  verified in `include/crypto/utils.h`.
- **[Phase 2]** Local `ocs-aes.c:1285` still uses `memcmp`.
- **[Phase 3]** `git blame -L 1269,1286`: `8857433245138` (v5.11 driver
  add). Ancestor of HEAD: yes. Candidate SHA ancestor of HEAD: **no**.
- **[Phase 3]** `c616fb0cbae8a` (`crypto/utils.h`) is ancestor of HEAD.
- **[Phase 3]** Sibling GCM `353b3a85136f2` not in HEAD; touches a
  different file.
- **[Phase 3]** In-tree timing-leak precedent: `79960943fdc11`
  (talitos), `cb8affb55c7e6` (nx), both Cc: stable.
- **[Phase 4]** `b4 dig -c/-a/-w`: v1 only; lore msgid
  `anYGKPaCNBgACGqK@david.gall`; To/Cc Herbert, davem, linux-crypto,
  gregkh.
- **[Phase 4]** Herbert “All applied. Thanks.” on the 1/2 GCM post
  (lkml.iu.edu 2608.1/13636).
- **[Phase 4]** lore.kernel.org WebFetch: **403**. Stable-list search:
  no keembay hit found.
- **[Phase 5]** Call chain read in `keembay-ocs-aes-core.c`: CCM
  `kmb_ocs_aead_common` → engine → `kmb_ocs_aead_run` → `ocs_aes_ccm_op`
  → `ccm_compare_tag_to_yr`.
- **[Phase 5]** Remaining GCM `memcmp` at `keembay-ocs-aes-core.c:922`.
- **[Phase 6]** `git apply --check` of `ff2ac77a034e0`: hunks succeed at
  offset −1.
- **[Phase 6]** `CRYPTO` selects `CRYPTO_LIB_UTILS`;
  `lib/crypto/memneq.c` present.
- **[Phase 7]** `ARCH_KEEMBAY` = Intel Movidius Keem Bay; driver
  `depends on ARCH_KEEMBAY || COMPILE_TEST`.
- **[Phase 8]** Algs `ccm(aes)` / `ccm(sm4)` with
  `CRYPTO_ALG_KERN_DRIVER_ONLY` verified in `keembay-ocs-aes-core.c` /
  `include/linux/crypto.h`.
- **UNVERIFIED:** practical remote exploitability of this MMIO-backed
  `memcmp`; full lore HTML (403).

**YES**

 drivers/crypto/intel/keembay/ocs-aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/intel/keembay/ocs-aes.c b/drivers/crypto/intel/keembay/ocs-aes.c
index bb6f33f6b4d39..13ba7573617fe 100644
--- a/drivers/crypto/intel/keembay/ocs-aes.c
+++ b/drivers/crypto/intel/keembay/ocs-aes.c
@@ -17,6 +17,7 @@
 
 #include <crypto/aes.h>
 #include <crypto/gcm.h>
+#include <crypto/utils.h>
 
 #include "ocs-aes.h"
 
@@ -1283,7 +1284,7 @@ static inline int ccm_compare_tag_to_yr(struct ocs_aes_dev *aes_dev,
 				 (i * sizeof(u32)));
 	}
 
-	return memcmp(tag, yr, tag_size_bytes) ? -EBADMSG : 0;
+	return crypto_memneq(tag, yr, tag_size_bytes) ? -EBADMSG : 0;
 }
 
 /**
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.6] crypto: sa2ul - use crypto_memneq() to compare AEAD tag

[Sasha Levin]

From: "David C.C.M. Gall" <david.ccm.gall@googlemail.com>

[ Upstream commit 7064af16d2b418d61571dba9bb0116a547ade124 ]

Use crypto_memneq() for a constant-time comparison.

sa_aead_dma_in_callback() compares the computed authentication tag
against the received tag with memcmp(), which short-circuits on the
first differing byte. An attacker who can submit decrypt requests and
observe completion latency could recover the expected tag byte by byte.

Valid tag forgery for AEAD breaks the INT-CTXT guarantee.

Assisted-by: gregkh_clanker_t1000
Signed-off-by: David C.C.M. Gall <david.ccm.gall@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **6.12.111** (`pending-6.12`). The buggy `memcmp()` of
the AEAD tag is present in `sa_aead_dma_in_callback()`, and this one-
line constant-time swap should be backported here.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: **[crypto: sa2ul]** **[use]** use `crypto_memneq()` to compare
AEAD tag. Subsystem is the TI K3 SA2UL hardware crypto driver. The verb
is “use” with an explicit constant-time replacement; the body describes
a timing leak.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- **Fixes:** none (expected for this review pipeline)
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none
- **Acked-by:** none
- **Link:** none in the commit; lore found via `b4 dig`
- **Cc: stable:** none (expected)
- **Assisted-by:** `gregkh_clanker_t1000` (tool-assisted; not a quality
  tag)
- **Signed-off-by:** David C.C.M. Gall (author); Herbert Xu (crypto
  maintainer)
- Ignore any pipeline “Upstream commit” / Sasha Levin SOB if present —
  they are not a selection signal

Notable: crypto maintainer SOB after applying v1 unchanged. No syzbot,
no multi-user reports.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** `sa_aead_dma_in_callback()` compares the computed AEAD
  authentication tag to the received tag with `memcmp()`, which returns
  on the first mismatched byte.
- **Symptom / failure mode:** An attacker who can submit decrypts and
  observe completion latency can recover the expected tag byte-by-byte
  (timing side channel).
- **Consequence:** Valid tag forgery breaks AEAD **INT-CTXT** (integrity
  of ciphertext).
- **Version info:** none in the message.
- **Root cause:** non-constant-time tag compare on the AEAD decrypt
  completion path.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: Not a hidden fix. This is an explicit crypto-security (timing)
fix, same class as historical `crypto_memneq()` ICV/tag conversions.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

**Step 2.1: INVENTORY THE CHANGES**

Record:
- File: `drivers/crypto/sa2ul.c` — **+2 / −1** (net +1, 3-line change)
- Functions: include block; `sa_aead_dma_in_callback()`
- Scope: **single-file surgical fix**

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Hunk 1 (include):** add `#include <crypto/utils.h>` so
  `crypto_memneq()` is declared. `include/crypto/utils.h` exists in this
  tree; `crypto/internal/aead.h` already pulls `crypto/algapi.h` →
  `crypto/utils.h`, so the include is explicit but not a functional
  dependency.
- **Hunk 2 (decrypt completion):** on decrypt (`!rxd->enc`), after
  copying the received tag, replace
  `err = memcmp(&mdptr[4], auth_tag, authsize) ? -EBADMSG : 0`
  with
  `err = crypto_memneq(&mdptr[4], auth_tag, authsize) ? -EBADMSG : 0`.
- Encrypt path is unchanged (it writes the tag out).
  Error/free/`aead_request_complete()` are unchanged.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record:
- **Category:** memory-safety / crypto correctness — **timing side
  channel** on AEAD tag compare (not UAF/leak/lock).
- **Mechanism:** `memcmp()` short-circuits; `crypto_memneq()` is
  documented as comparing without leaking timing
  (`include/crypto/utils.h`). Same boolean sense: 0 = equal, nonzero =
  not equal, so `-EBADMSG` vs `0` is preserved.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- Obviously correct: drop-in replacement used throughout the crypto
  stack and other HW AEAD drivers (`talitos`, `atmel-aes`, `nx`, `ccp`,
  etc.).
- Minimal; no API/struct/locking changes.
- Regression risk: **very low**. Slightly more work per decrypt
  (constant-time over `authsize`, typically 12–32 bytes) is negligible
  vs DMA/IRQ.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- Buggy `memcmp()` introduced in **`d2c8ac187fc92`** (“crypto: sa2ul -
  Add AEAD algorithm support”, Keerthy, 2020-07-23).
- Present since **v5.9-era** driver addition; in this 6.12 tree (`git
  merge-base --is-ancestor d2c8ac187fc92 HEAD` succeeded).
- Blame on the callback still shows that 2020 origin for the compare.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: No `Fixes:` tag. The introducing commit is `d2c8ac187fc92`, and
it **is** in this tree.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record: Recent `sa2ul.c` work here is unrelated (probe pool failure,
fallback names, MODULE_DESCRIPTION, setkey errors). No prerequisite
refactor of the tag compare. Standalone.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Author is not the subsystem maintainer. Same-day sibling patches
on origin/master: keembay CCM/GCM `crypto_memneq()` conversions
(`353b3a85136f2`, `ff2ac77a034e0`). Herbert Xu applied this series.
Historical precedent in **this** tree: `79960943fdc11` (talitos) and
`cb8affb55c7e6` (nx) — same bug class, both **Cc: stable**.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: None. `crypto_memneq()` lives in `lib/crypto/memneq.c`
(`CRYPTO_LIB_UTILS`, selected by `CRYPTO`). Driver already `select
CRYPTO_ALGAPI`. Patch applies standalone. `git show 7064af16d2b41 | git
apply --check` **exit 0** on this tree. Commit **not** already an
ancestor of HEAD.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- `b4 dig -c 7064af16d2b418d61571dba9bb0116a547ade124` →
  https://patch.msgid.link/anX9UKJ66Aak4ICV@fudgebox
- **v1 only** (`b4 dig -a`); committed version is v1.
- Thread: author submission (2026-08-07); Herbert Xu “Patch applied.
  Thanks.” (2026-08-15). **No NAK, no review risk comments, no Cc:
  stable suggestion.**

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record (`b4 dig -w`): To/Cc Herbert Xu, David S. Miller, linux-crypto,
linux-kernel, gregkh@linuxfoundation.org. Subsystem maintainer applied
it.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: No Reported-by / Link / bugzilla / syzbot. Bug is from code
review of the `memcmp()` decrypt path, not a field crash.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: Same author, same day: keembay GCM/CCM `crypto_memneq()`
patches. This sa2ul patch is self-contained; keembay is a different
driver and is **not** a prerequisite. keembay is also not in this 6.12
tree.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: **UNVERIFIED** — lore.kernel.org/stable returned an Anubis bot
challenge (HTTP 403 / JS gate). Original linux-crypto thread had no
stable discussion.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: IDENTIFY KEY FUNCTIONS**

Record: `sa_aead_dma_in_callback()`; `crypto_memneq()` (callee).

**Step 5.2: TRACE CALLERS**

Record:
- Callback assigned in `sa_aead_run()` (`sa_req.callback =
  sa_aead_dma_in_callback`).
- `sa_aead_run()` called from `sa_aead_encrypt()` / `sa_aead_decrypt()`.
- Those are `.encrypt` / `.decrypt` for
  `authenc(hmac(sha1),cbc(aes))-sa2ul` and
  `authenc(hmac(sha256),cbc(aes))-sa2ul` (priority **3000**).
- Completes in DMA RX callback context, then `aead_request_complete()`.

**Step 5.3: TRACE CALLEES**

Record: `sa_sync_from_device`, `dmaengine_desc_get_metadata_ptr`,
`scatterwalk_map_and_copy`, `sa_free_sa_rx_data`,
`aead_request_complete`. After the change, decrypt also calls
`crypto_memneq()`. No new locks or allocations.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: Reachable from the kernel crypto AEAD API. Algorithms have
`CRYPTO_ALG_KERN_DRIVER_ONLY` but **not** `CRYPTO_ALG_INTERNAL`.
`KERN_DRIVER_ONLY` means “HW offload, not a CPU ISA helper”
(`include/linux/crypto.h`); AF_ALG even allows that bit in
`salg_feat`/`salg_mask`. Userspace **can** bind these algs when
`CRYPTO_USER_API_AEAD` is enabled. Kernel users (e.g. IPsec ESP with
authenc) can also select this high-priority driver.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Same `memcmp`→`crypto_memneq` tag/ICV pattern already used in
`drivers/crypto/talitos.c`, `atmel-aes.c`, `nx-aes-gcm.c`, `nx-aes-
ccm.c`, `ccp-ops.c`, etc. Remaining `memcmp` of auth material in this
tree: `drivers/crypto/qce/aead.c` (different driver). sa2ul had the last
such compare in this file.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: **Yes.** `drivers/crypto/sa2ul.c` line 1722:

`err = memcmp(&mdptr[4], auth_tag, authsize) ? -EBADMSG : 0;`

Introduced 2020 (`d2c8ac187fc92`); still here. Tree is 6.12.111.
Upstream fix `7064af16d2b41` is **not** an ancestor of HEAD.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **Clean apply** (`git apply --check` succeeded). Include site
and callback context match origin. `include/crypto/utils.h` exists
(moved in `c616fb0cbae8a`, long before 6.12).

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: No `crypto_memneq` sa2ul commit in this tree. No alternate tag-
compare fix. nx/talitos timing-leak fixes are already present; they do
not cover sa2ul.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record: **drivers/crypto/sa2ul.c** — TI K3 Security Accelerator.
**IMPORTANT** for those platforms (crypto offload used by
IPsec/VPN/etc.), **not CORE**. `CONFIG_CRYPTO_DEV_SA2UL` depends on
`ARCH_K3 || COMPILE_TEST`; **`CONFIG_CRYPTO_DEV_SA2UL=m` is in
`arch/arm64/configs/defconfig`**.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Mature driver (added 2020). Modest ongoing fixes in 6.12. This
is a long-standing compare bug, not a regression from recent refactor.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: **Driver-specific / platform-specific:** TI K3 SoCs
(AM62/AM64/AM65, J721e, etc.) with SA2UL AEAD offload enabled. Not
universal.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: Trigger is **every hardware AEAD decrypt** that takes the non-
fallback path (`sa_aead_dma_in_callback` decrypt branch). Userspace can
hit it via AF_ALG if user-API AEAD is enabled; kernel IPsec/authenc can
hit it without userspace crypto. Timing exploitation needs many decrypts
plus latency observation — classic, not a one-shot crash. Unprivileged
trigger is possible where AF_ALG AEAD is exposed.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record:
- **Failure mode:** timing leak of the expected authentication tag →
  theoretical **tag forgery**, breaking AEAD integrity.
- **Severity: HIGH** (crypto integrity / security). Not a panic/UAF.
  DMA/IRQ noise makes a practical oracle harder than a userspace
  `memcmp` of a hot buffer, but the kernel crypto API treats non-
  constant-time ICV checks as real bugs (talitos/nx were Cc: stable for
  the same reason). `crypto_memneq()` exists specifically for this.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit:** closes a known AEAD INT-CTXT hole on a defconfig-enabled
  ARM64 HW driver; matches established crypto policy.
- **Risk:** very low (one compare + include; return-value polarity
  matches).
- **Ratio:** benefit > risk for this stable tree.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

**FOR:**
- Real AEAD tag compare uses variable-time `memcmp()` on decrypt
  complete.
- Breaks INT-CTXT if exploited; same class previously backported
  (talitos, nx) with Cc: stable.
- Buggy code has been in this file since 2020 and is in 6.12.111.
- 3-line, obviously correct, applies cleanly; `crypto_memneq()` already
  in this tree.
- Crypto maintainer applied v1 with no objections.
- Driver is in arm64 defconfig; path is a real decrypt completion, not
  dead code.

**AGAINST:**
- No user report / CVE / syzbot.
- Practical timing through DMA+IRQ is noisy (harder oracle than a tight
  userspace loop).
- Affects TI K3 SA2UL users, not all 6.12 systems.
- No explicit Cc: stable (not a negative per the review rules).

**UNRESOLVED:**
- Whether this SHA was already discussed on stable@ (lore blocked).
- No measured exploit against sa2ul specifically.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — drop-in `crypto_memneq()`;
   maintainer applied; API used kernel-wide.
2. Fixes a real bug that affects users? **PASS** — non-constant-time
   AEAD tag verify on HW decrypt.
3. Important issue (crash, security, corruption, deadlock)? **PASS** —
   security (AEAD integrity / timing). Severity HIGH, not a panic.
4. Small and contained? **PASS** — 3 lines, one file, one function.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS** — clean apply; helpers present.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: Not a device-ID / quirk / DT / build / docs exception. Qualifies
as a **small security correctness fix**.

**Step 9.4: MAKE YOUR DECISION**

This is a surgical, low-risk fix for a real AEAD tag timing leak in code
that exists in 6.12.111. Stable policy has historically taken this exact
class of change. Backport to this tree.

---

### What the commit solves for stable users

On TI K3 boards using SA2UL AEAD offload, decrypt completion compared
the computed MAC to the packet tag with `memcmp()`. That can leak how
many leading tag bytes matched via completion latency and, in the
standard model, enable tag forgery (INT-CTXT failure). Replacing it with
`crypto_memneq()` makes the compare constant-time without changing
success/failure semantics.

### Stable rules / risk vs benefit

Meets all six criteria: small, obviously correct, no new API, applies
cleanly here, fixes a crypto-integrity bug. Risk is essentially the cost
of a 16–32 byte constant-time XOR loop. Benefit is aligning this long-
lived driver with the rest of the crypto stack.

### Concerns

None that block backport: no missing prereqs, no follow-up that rewrote
the callback, include header already in 6.12. Practical exploitability
is not proven in the field; that does not make the compare correct.

---

Verification:
- [Phase 1] Parsed subject/tags/body from `git show 7064af16d2b41`; no
  Fixes/Reported-by/Cc: stable; SOB Herbert Xu; Assisted-by
  gregkh_clanker_t1000
- [Phase 2] Diff: `drivers/crypto/sa2ul.c` +2/−1; include
  `crypto/utils.h`; `memcmp` → `crypto_memneq` in
  `sa_aead_dma_in_callback` decrypt branch
- [Phase 2] Confirmed `crypto_memneq` returns 0 if equal, 1 otherwise
  (`include/crypto/utils.h` lines 56–70) — same ternary as `memcmp`
- [Phase 3] `git describe HEAD` / Makefile: **6.12.111**, branch
  `pending-6.12`
- [Phase 3] `git merge-base --is-ancestor 7064af16d2b41 HEAD` → not
  ancestor; `d2c8ac187fc92` **is** ancestor
- [Phase 3] `git log origin/master -S 'memcmp(&mdptr[4]' --
  drivers/crypto/sa2ul.c` → intro `d2c8ac187fc92`, fix `7064af16d2b41`
- [Phase 3] Blame on local callback: memcmp path from 2020 AEAD add
- [Phase 3] Same-class stable precedent in this tree: `79960943fdc11`
  (talitos), `cb8affb55c7e6` (nx), both Cc: stable
- [Phase 3] `git apply --check` of `7064af16d2b41` → success
- [Phase 4] `b4 dig -c/-a/-w/-m`: lore
  https://patch.msgid.link/anX9UKJ66Aak4ICV@fudgebox ; v1 only; Herbert
  “Patch applied”; To linux-crypto + Herbert
- [Phase 4] WebFetch lore 403; stable@ search blocked by Anubis —
  UNVERIFIED for stable-list history
- [Phase 5] Callers: `sa_aead_run` ←
  `sa_aead_encrypt`/`sa_aead_decrypt`; algs
  `authenc(hmac(sha1|sha256),cbc(aes))-sa2ul`
- [Phase 5] `CRYPTO_ALG_KERN_DRIVER_ONLY` is not `CRYPTO_ALG_INTERNAL`;
  AF_ALG allows that flag (`crypto/af_alg.c`)
- [Phase 5] Other drivers already use `crypto_memneq` for AEAD tags
  under `drivers/crypto/`
- [Phase 6] Local line 1722 still `memcmp`; `include/crypto/utils.h`
  present; `CRYPTO` selects `CRYPTO_LIB_UTILS`; `lib/crypto/memneq.c`
  exports `__crypto_memneq`
- [Phase 6] `arch/arm64/configs/defconfig` has
  `CONFIG_CRYPTO_DEV_SA2UL=m`
- [Phase 7] Driver added 2020 (`7694b6ca649fe`); Kconfig
  `CRYPTO_DEV_SA2UL` depends on `ARCH_K3`
- [Phase 8] Failure mode: AEAD tag timing leak / INT-CTXT, severity
  HIGH; apply risk very low
- UNVERIFIED: stable@ mailing list discussion; real-world exploit of
  this specific DMA-callback timing channel

**YES**

 drivers/crypto/sa2ul.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index 73034aeb63862..4a766e4351970 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -22,6 +22,7 @@
 
 #include <crypto/aes.h>
 #include <crypto/authenc.h>
+#include <crypto/utils.h>
 #include <crypto/des.h>
 #include <crypto/internal/aead.h>
 #include <crypto/internal/hash.h>
@@ -1688,7 +1689,7 @@ static void sa_aead_dma_in_callback(void *data)
 		scatterwalk_map_and_copy(auth_tag, req->src, start, authsize,
 					 0);
 
-		err = memcmp(&mdptr[4], auth_tag, authsize) ? -EBADMSG : 0;
+		err = crypto_memneq(&mdptr[4], auth_tag, authsize) ? -EBADMSG : 0;
 	}
 
 	sa_free_sa_rx_data(rxd);
-- 
2.53.0