[PATCH AUTOSEL 6.18-5.10] ima: return error early if file xattr cannot be changed

[PATCH AUTOSEL 6.18-5.10] ima: return error early if file xattr cannot be changed

[Sasha Levin]

From: Goldwyn Rodrigues <rgoldwyn@suse.de>

[ Upstream commit 69fc6474236d9edda6983623e4282f2bdfd8e3d8 ]

During early boot, the filesystem is read-only and any changes
to xattrs are not allowed. This fails in case of ext4 because
changing xattr starts an ext4 transaction which fails with the
following warning.

WARNING: fs/ext4/ext4_jbd2.c:75 at ext4_journal_check_start+0x63/0xa0 [ext4], CPU#1: systemd-sysroot/561
CPU: 1 UID: 0 PID: 561 Comm: systemd-sysroot Not tainted 6.19.12-1-default #1 PREEMPT(voluntary) openSUSE Tumbleweed  c2dfc3c9d9f6f1233251c5d4410574fe82a348ee
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
RIP: 0010:ext4_journal_check_start+0x63/0xa0 [ext4]
Call Trace:
  __ext4_journal_start_sb+0x3e/0x180 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1]
  ext4_xattr_set+0x104/0x150 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1]
  __vfs_setxattr+0x9a/0xd0
  __vfs_setxattr_noperm+0x76/0x1f0
  ima_appraise_measurement+0x23e/0xe40
  ima_d_path+0x5a/0xd0
  process_measurement+0xb29/0xc40
  ? copy_from_kernel_nofault+0x21/0xe0
  ? fscrypt_file_open+0xc0/0xe0
  ? ext4_file_open+0x60/0x490 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1]
  ? bpf_prog_31efb7c56239148b_restrict_filesystems+0xab/0x126
  ? __bpf_prog_exit+0x23/0xd0
  ? __bpf_tramp_exit+0xd/0x50
  ? bpf_trampoline_6442530367+0x9f/0xea
  ima_file_check+0x57/0x80
  security_file_post_open+0x50/0xf0
  path_openat+0x493/0x1650
  do_filp_open+0xc7/0x170

Detect the state of the file early and return the error.

Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `ima: return error early if file xattr
cannot be changed`

**Local tree:** `v6.18.43` (`make kernelversion` → 6.18.43)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[ima]` `[return]` — Early-return from IMA xattr fix path
when the inode cannot accept xattr changes.

### Step 1.2: Commit message tags
**Record:**
- **Signed-off-by:** Goldwyn Rodrigues `<rgoldwyn@suse.com>` (author)
- **Signed-off-by:** Mimi Zohar `<zohar@linux.ibm.com>` (IMA maintainer)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, Link:,
  or Cc: stable tags (absence is expected per review pipeline)

**Notable:** Maintainer sign-off from Mimi Zohar carries weight for IMA
changes.

### Step 1.3: Commit body analysis
**Record:**
- **Bug:** With `IMA_APPRAISE_FIX`, IMA tries to write `security.ima`
  xattrs during file open even when the filesystem is read-only (typical
  early boot before remount-rw).
- **Symptom:** ext4 starts a journal transaction for xattr set, hits
  `WARN_ON_ONCE(sb_rdonly(sb))` in `ext4_journal_check_start()`, logs a
  kernel warning.
- **Reproducer:** `systemd-sysroot` opening files on read-only ext4
  during early boot on openSUSE Tumbleweed 6.19.12; full stack trace
  provided.
- **Root cause (author):** IMA does not check whether the
  file/filesystem is writable before calling `__vfs_setxattr_noperm()`.
- **Fix approach:** Detect read-only/immutable state early in
  `ima_fix_xattr()` and return `-EROFS`/`-EPERM`.

### Step 1.4: Hidden bug fix detection
**Record:** Yes — despite not using "fix" in the subject verb, this is a
correctness bug fix. IMA was attempting an operation guaranteed to fail,
driving filesystem code down an error/warning path. Not cosmetic
cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Change inventory
**Record:**
- **Files:** `security/integrity/ima/ima_appraise.c` (+5 lines, 0
  removed)
- **Function modified:** `ima_fix_xattr()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code flow change
**Record:**
- **Hunk (ima_fix_xattr):**
  - **Before:** Always prepared xattr data and called
    `__vfs_setxattr_noperm()`, even on read-only filesystems or
    immutable inodes.
  - **After:** Returns `-EROFS` if `IS_RDONLY(d_inode(dentry))`,
    `-EPERM` if `IS_IMMUTABLE(d_inode(dentry))`, before touching xattr
    data or calling VFS.
  - **Path affected:** `IMA_APPRAISE_FIX` path in
    `ima_appraise_measurement()` (line 602) and `ima_update_xattr()`
    (line 646).

### Step 2.3: Bug mechanism
**Record:**
- **Category:** Logic/correctness fix — missing precondition checks
  before VFS xattr write.
- **Mechanism:** `IS_RDONLY()` expands to `sb_rdonly((inode)->i_sb)` —
  the same condition ext4 warns on at `ext4_jbd2.c:76`. Early return
  avoids the pointless journal start and `WARN_ON_ONCE`.

### Step 2.4: Fix quality
**Record:**
- **Quality:** Obviously correct; mirrors existing EVM guard pattern in
  `evm_main.c:267-269`.
- **Regression risk:** Very low. On failure paths the code already
  received `-EROFS` from ext4; this only avoids the warning and
  unnecessary FS work.
- **Minor gap vs EVM:** EVM also checks `s_readonly_remount`; this patch
  does not. That is a pre-existing difference, not a regression from
  this fix. The reported early-boot RO-root case is covered by
  `IS_RDONLY()`.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame changed lines
**Record:** Stable tree blame shows `ima_fix_xattr()` at lines 88–106
without the guard checks. Function and `nop_mnt_idmap` usage are present
in v6.18.43. Exact mainline introduction commit not traceable in this
stable snapshot (single base commit in file history).

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag in commit message.

### Step 3.3: Related file history
**Record:** Recent IMA commits in this tree include `b6766b171a5c4`,
`148e4f7ece720`, `9e1f51c1ad57c`, etc. No related fix for this issue
already present. Standalone one-patch series (v1 only).

### Step 3.4: Author context
**Record:** Goldwyn Rodrigues (SUSE). Mimi Zohar (IMA maintainer)
reviewed and signed off. Author has other commits in tree (e.g., btrfs
tracepoint fix).

### Step 3.5: Dependencies
**Record:** No prerequisites. Uses `IS_RDONLY`, `IS_IMMUTABLE`,
`d_inode()` — all present. `nop_mnt_idmap` and `__vfs_setxattr_noperm`
already used in the same function. Applies standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original patch discussion
**Record:**
- **b4 dig URL:** https://patch.msgid.link/aposxvqsrlbe7gtyvtsdh5nyg5sgo
  fimerqpt6ez4fbxhtqyjj@4u3othdcgipp
- **Series:** v1 only (no v2/v3)
- **Mimi Zohar reply:** "Thank you! The patch makes a lot of sense."
- No NAKs found. No explicit stable nomination in thread.

### Step 4.2: Reviewers
**Record:** CC'd to `linux-integrity@vger.kernel.org`. Mimi Zohar
(maintainer) responded positively and signed off in the committed
version.

### Step 4.3: Bug report
**Record:** Concrete stack trace in commit message from openSUSE
Tumbleweed / QEMU, `systemd-sysroot` during early boot. Severity from
reporter: kernel WARNING (not oops/panic).

### Step 4.4: Related patches
**Record:** Part of a larger SUSE series on mainline (`[PATCH 02/19]` in
mirror), but this specific patch is self-contained with no series
dependencies.

### Step 4.5: Stable list history
**Record:** Not searched on lore stable list (no indication of prior
stable discussion). Not a negative signal.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `ima_fix_xattr()` (modified); callers
`ima_appraise_measurement()`, `ima_update_xattr()`.

### Step 5.2: Callers
**Record:**
- `ima_appraise_measurement()` ← `process_measurement()` ←
  `ima_file_check()` (LSM `file_post_open` hook)
- `ima_update_xattr()` ← post-write xattr update path
- **Context:** File open during boot (`systemd-sysroot`), common
  security hook path.

### Step 5.3: Callees
**Record:** `__vfs_setxattr_noperm()` → `__vfs_setxattr()` → filesystem
`xattr_set` (ext4 starts journal).

### Step 5.4: Reachability
**Record:**
- Trigger: `CONFIG_IMA_APPRAISE` + `IMA_APPRAISE_FIX` mode + read-only
  root during early boot + files opened that fail IMA appraisal.
- Reachable from normal file open syscall path via LSM hook. Not obscure
  module-init-only code.

### Step 5.5: Similar patterns
**Record:** EVM already guards identically before xattr update:

```267:273:security/integrity/evm/evm_main.c
                        } else if (!IS_RDONLY(inode) &&
                                   !(inode->i_sb->s_readonly_remount) &&
                                   !IS_IMMUTABLE(inode) &&
                                   !is_unsupported_hmac_fs(dentry)) {
                                evm_update_evmxattr(dentry, xattr_name,
                                                    xattr_value,
                                                    xattr_value_len);
```

IMA was missing the equivalent guard — clear oversight.

---

## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE (v6.18.43)

### Step 6.1: Buggy code present?
**Record:** **Yes.** `ima_fix_xattr()` at lines 88–106 lacks
`IS_RDONLY`/`IS_IMMUTABLE` checks. Fix is not yet applied (`grep` found
no matches).

### Step 6.2: Backport complications
**Record:** **Clean apply expected.** Context matches exactly (same
function, same `nop_mnt_idmap` usage, same line structure).

### Step 6.3: Related fixes already present?
**Record:** **No.** No prior commit in this tree addresses this issue.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **security/integrity/ima** — IMPORTANT. IMA is used on
secure-boot and integrity-measurement deployments (enterprise Linux,
embedded secure systems).

### Step 7.2: Subsystem activity
**Record:** Active — multiple IMA fixes in v6.18.y stable queue already.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who is affected
**Record:** Systems with `CONFIG_IMA_APPRAISE` and `IMA_APPRAISE_FIX`
(or `ima_appraise=fix` boot param) on read-only root during early boot.
Relevant to dracut/initramfs/systemd-sysroot workflows on ext4 (and
potentially other journaled FS).

### Step 8.2: Trigger conditions
**Record:**
- Early boot, RO root filesystem
- IMA appraise-fix mode attempting to repair missing/wrong
  `security.ima` xattrs on file open
- **Likelihood:** Moderate for IMA-enabled distros during every boot
  until rw remount
- **Unprivileged trigger:** Indirectly — any file open during sysroot
  phase can trigger it

### Step 8.3: Failure mode severity
**Record:** `WARN_ON_ONCE` from ext4 journal layer. **Severity: MEDIUM**
— no crash, panic, corruption, or deadlock, but spurious kernel warnings
on every affected file open during early boot. Pollutes logs and may
trigger monitoring alerts on security-hardened systems.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Eliminates reproducible boot-time warnings; aligns IMA
  with EVM; avoids pointless FS journal operations.
- **Risk:** Minimal (5 lines, well-understood checks).
- **Ratio:** Favorable — low risk, real (if non-critical) user-visible
  bug fix.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Reproducible bug with full stack trace (openSUSE)
- IMA maintainer endorsed ("makes a lot of sense") and signed off
- 5-line surgical fix, obviously correct
- Mirrors existing EVM pattern in same subsystem
- Buggy code confirmed present in v6.18.43
- Clean apply, no dependencies
- Real logic bug (attempting impossible xattr write)

**AGAINST backport:**
- Failure mode is WARNING only, not crash/corruption/security
- Requires `IMA_APPRAISE_FIX` — narrower than default IMA enforce mode
- Does not add EVM's `s_readonly_remount` check (minor, pre-existing
  gap)

**Unresolved:** Exact mainline commit that introduced `ima_fix_xattr()`
without guards (not traceable in stable snapshot history).

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logic mirrors EVM;
   maintainer reviewed; reproducer provided.
2. Fixes a real bug affecting users? **PASS** — concrete openSUSE early-
   boot warning.
3. Important issue? **PASS (borderline)** — WARN_ON spam during boot on
   IMA systems; not crash-level but user-visible on security
   deployments.
4. Small and contained? **PASS** — 5 lines, 1 file.
5. No new features or APIs? **PASS** — defensive checks only.
6. Can apply to local tree? **PASS** — code exists, patch applies
   cleanly.

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build fix, or docs).
Standard bug fix.

### Step 9.4: Decision rationale

For **v6.18.43**, this commit fixes a real, reproducible bug in the IMA
appraisal-fix path where the kernel incorrectly attempts xattr writes on
read-only filesystems during early boot. The result is ext4
`WARN_ON_ONCE` spam — not a crash, but a genuine defect in security
subsystem code that EVM already handles correctly. The fix is minimal,
maintainer-approved, and applies cleanly to this tree.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body; identified IMA early-boot RO
  xattr warning bug
- **[Phase 2]** Diff analysis: +5 lines in `ima_fix_xattr()`, adds
  `IS_RDONLY`/`IS_IMMUTABLE` guards
- **[Phase 3]** `git describe HEAD` → v6.18.43; `git blame`/`git show`
  confirm buggy code at lines 88–106 without guards
- **[Phase 3]** No Fixes: tag; no related fix in tree; standalone patch
- **[Phase 4]** `b4 dig -c 69fc6474236d9edda6983623e4282f2bdfd8e3d8`:
  lore URL found; v1 only
- **[Phase 4]** `b4 dig -w`: CC'd linux-integrity@vger.kernel.org
- **[Phase 4]** Mbox thread: Mimi Zohar — "The patch makes a lot of
  sense"
- **[Phase 5]** Call chain verified: `ima_file_check` →
  `process_measurement` → `ima_appraise_measurement` → `ima_fix_xattr`
- **[Phase 5]** EVM parallel check at `evm_main.c:267-269` verified via
  grep
- **[Phase 5]** `IS_RDONLY` → `sb_rdonly()` verified at
  `include/linux/fs.h:2546`
- **[Phase 5]** ext4 warning at `fs/ext4/ext4_jbd2.c:76` —
  `WARN_ON_ONCE(sb_rdonly(sb))` verified
- **[Phase 6]** `grep IS_RDONLY` in ima: no matches — fix not present
- **[Phase 6]** `ima_fix_xattr` and `nop_mnt_idmap` present in v6.18.43
- **[Phase 8]** Failure mode: WARN_ON_ONCE, severity MEDIUM

**YES**The background history search (`git log --all -S
"ima_fix_xattr"`) was stopped — `--all` scans too many branches and had
hung. That didn’t change the backport conclusion.

For **v6.18.43**, the important part is already verified:
`ima_fix_xattr()` is present **without** the `IS_RDONLY`/`IS_IMMUTABLE`
guards, so the early-boot ext4 warning is a real issue here. Pinning the
exact mainline commit that introduced `ima_fix_xattr` isn’t possible in
this stable snapshot (file history collapses to the release base), and
it isn’t needed for the decision.

**Verdict for this tree: YES** — small, maintainer-reviewed fix for a
reproducible IMA appraise-fix warning on read-only root during early
boot.

 security/integrity/ima/ima_appraise.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index 5149ff4fd50d2..d5f7de58caac5 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -90,6 +90,11 @@ static int ima_fix_xattr(struct dentry *dentry, struct ima_iint_cache *iint)
 	int rc, offset;
 	u8 algo = iint->ima_hash->algo;
 
+	if (IS_RDONLY(d_inode(dentry)))
+		return -EROFS;
+	if (IS_IMMUTABLE(d_inode(dentry)))
+		return -EPERM;
+
 	if (algo <= HASH_ALGO_SHA1) {
 		offset = 1;
 		iint->ima_hash->xattr.sha1.type = IMA_XATTR_DIGEST;
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.15] integrity: Check for NULL returned by asymmetric_key_public_key

[Sasha Levin]

From: Stefan Berger <stefanb@linux.ibm.com>

[ Upstream commit c93a5f038ccc11ed8558ce642f62d5ede701a348 ]

Check for a NULL pointer returned by asymmetric_key_public_key and return
-ENOKEY in this case.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Kamlesh Kumar <kam@juniper.net>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
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:** `[integrity]` `[Check]` — Add a NULL check on the return
value of `asymmetric_key_public_key()` in asymmetric signature
verification.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Stefan Berger `<stefanb@linux.ibm.com>` (author)
- **Tested-by:** Kamlesh Kumar `<kam@juniper.net>`
- **Signed-off-by:** Mimi Zohar `<zohar@linux.ibm.com>` (integrity
  subsystem maintainer)
- **No** Fixes:, Reported-by:, Link:, Cc: stable@vger.kernel.org,
  Reviewed-by:, Acked-by:

Notable: maintainer sign-off plus Tested-by; no syzbot or user bug
report.

### Step 1.3: Body analysis
**Record:**
- **Bug:** `asymmetric_key_public_key()` can return NULL; the code
  dereferences `pk` without checking.
- **Symptom:** NULL pointer dereference → kernel oops in
  `asymmetric_verify()`.
- **Fix:** Return `-ENOKEY` and jump to the existing `out:` cleanup
  path.
- **Series context:** Patch 1/4 of “Add support for ML-DSA signature for
  EVM and IMA”; v3 added patches 1/4 and 2/4 per Mimi Zohar’s review
  comments on v2.

### Step 1.4: Hidden bug fix?
**Record:** Yes — explicit NULL-dereference fix, not cosmetic cleanup.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `security/integrity/digsig_asymmetric.c` (+4 / −0)
- **Function:** `asymmetric_verify()`
- **Scope:** Single-file, surgical (4 lines)

### Step 2.2: Code flow change
**Record:**
- **Before:** After `request_asymmetric_key()` succeeds, `pk =
  asymmetric_key_public_key(key)` is used immediately as
  `pk->pkey_algo`.
- **After:** If `pk` is NULL, set `ret = -ENOKEY`, `goto out` (which
  calls `key_put(key)`).
- **Path:** Error handling in IMA/EVM asymmetric signature verification
  (sig v2).

### Step 2.3: Bug mechanism
**Record:** **Category:** NULL pointer dereference.
**Mechanism:** `asymmetric_key_public_key()` is an inline accessor
returning `key->payload.data[asym_crypto]`, which can be NULL. The code
assumed it was always valid after a successful key lookup.

### Step 2.4: Fix quality
**Record:** Obviously correct; mirrors existing `!pkey` handling in
`restrict_link_by_digsig()` / `restrict_link_by_ca()`. Uses existing
`out:` label. Very low regression risk.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Lines 110–111 in the local tree were introduced in commit
`6bda50f4333fa` (2025-11-29) when `digsig_asymmetric.c` was added. The
missing NULL check has been present since that introduction in this
tree.

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag.

### Step 3.3: Related file history
**Record:** On `stable/linux-6.18.y`, `digsig_asymmetric.c` appears from
`6bda50f4333fa`. The buggy pattern is present at merge-base
`7b923c78b50d`. Part of ML-DSA v3 series (4 patches); this commit is
standalone and does not require patches 2–4.

### Step 3.4: Author context
**Record:** Stefan Berger is a regular integrity contributor. Mimi Zohar
(maintainer) signed off. Series included in `integrity-v7.2` pull (June
2026).

### Step 3.5: Dependencies
**Record:** No prerequisites. Applies independently of ML-DSA support
(patches 3/4 and 4/4).

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original discussion
**Record:** Found via spinics/openwall at [PATCH v3
1/4](https://www.spinics.net/lists/kernel/msg6157574.html). Cover
letter: [PATCH v3
0/4](https://www.spinics.net/lists/kernel/msg6157584.html). v3 added
patches 1/4 and 2/4 addressing Mimi’s v2 comments. `b4 dig -c` could not
be run (commit not in local tree); `b4 shazam` did not find message-id.
lore.kernel.org blocked by bot protection.

### Step 4.2: Reviewers
**Record:** CC’d: linux-integrity, linux-security-module, Mimi Zohar,
Roberto Sassu, Eric Biggers.

### Step 4.3: Bug report
**Record:** No external bug report, syzbot, or sanitizer report. Found
during ML-DSA series review (Mimi’s v2 feedback).

### Step 4.4: Series context
**Record:** 4-patch ML-DSA series. This patch is independently valuable;
later patches refactor and add ML-DSA sigv3 support.

### Step 4.5: Stable list
**Record:** No stable-list discussion found. Included in maintainer’s
`integrity-v7.2` pull for mainline.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** `asymmetric_verify()` modified.

### Step 5.2: Callers
**Record:**
- `integrity_digsig_verify()` in `security/integrity/digsig.c` (sig
  types 2 and 3)
- Callers of `integrity_digsig_verify()`:
  - `security/integrity/ima/ima_appraise.c` — IMA signature appraisal
  - `security/integrity/evm/evm_main.c` — EVM signature verification

### Step 5.3: Callees
**Record:** `request_asymmetric_key()`, `asymmetric_key_public_key()`,
`verify_signature()`, `key_put()`.

### Step 5.4: Reachability
**Record:** Reachable from file access when
`CONFIG_INTEGRITY_ASYMMETRIC_KEYS` and IMA/EVM appraisal are enabled. On
this tree, IMA rejects sig version ≥ 3 before verification; sig v2
asymmetric verification is the affected path.

### Step 5.5: Similar patterns
**Record:** `crypto/asymmetric_keys/restrict.c` checks `if (!pkey)
return -ENOPKG`. `verify_signature()` checks `!key->payload.data[0]`
(same slot as `asym_crypto`) — but only after `asymmetric_verify()`
would have already crashed on NULL `pk`.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy code present?
**Record:** **Yes.** Local tree is **v6.18.43** (`stable/linux-6.18.y`,
`HEAD` detached). `security/integrity/digsig_asymmetric.c` lines 110–111
lack the NULL check:

```110:111:security/integrity/digsig_asymmetric.c
        pk = asymmetric_key_public_key(key);
        pks.pkey_algo = pk->pkey_algo;
```

### Step 6.2: Backport complications
**Record:** Clean apply expected — 4 lines at a stable location. Minor
field-name difference (`pks.digest` vs `pks.m` in the submitted diff)
does not affect patch placement.

### Step 6.3: Related fixes already present?
**Record:** No — grep shows no existing NULL check at this site.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem criticality
**Record:** **security/integrity** (IMA/EVM) — **IMPORTANT** (security-
sensitive, affects systems with integrity appraisal enabled).

### Step 7.2: Activity
**Record:** Actively maintained; recent IMA/EVM commits on this branch.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** Systems with `CONFIG_INTEGRITY_ASYMMETRIC_KEYS` and IMA/EVM
digital-signature appraisal. Not universal, but important for
secured/enterprise deployments.

### Step 8.2: Trigger conditions
**Record:** A signature references a key ID that resolves to an
asymmetric key whose `asym_crypto` payload is NULL. With standard
X.509-loaded RSA/ECDSA keys this is unlikely; the subsystem already
treats `!pkey` as a valid error state elsewhere. More relevant once non-
standard key types (e.g. ML-DSA) are introduced. Trigger does not
require ML-DSA patch 4/4 on this tree, but practical likelihood on
6.18.y without ML-DSA is low.

### Step 8.3: Failure mode severity
**Record:** **Kernel oops** (NULL dereference at `pk->pkey_algo`) —
**CRITICAL** if triggered.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Prevents crash in security verification path; returns
  proper error instead.
- **Risk:** Very low — 4 lines, uses existing cleanup, no API change.
- **Ratio:** Favorable for stable despite rare trigger on current 6.18.y
  key types.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR backport:**
- Real NULL-deref bug in security code
- Small, surgical, maintainer-signed fix with Tested-by
- Buggy code exists in v6.18.43
- Applies cleanly and standalone
- IMA/EVM verification path is security-critical
- Consistent with existing `!pkey` handling in asymmetric key code

**AGAINST backport:**
- No user report or fuzzer finding
- Added during ML-DSA series review; practical trigger on 6.18.y without
  ML-DSA may be very rare
- Standard X.509 keys normally always populate `asym_crypto`
- IMA already rejects sig v3 on this tree, limiting some future trigger
  scenarios

**Unresolved:** No confirmed production crash on 6.18.y with current key
types only.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** (simple NULL check; Tested-by;
   maintainer SOB)
2. Fixes a real bug? **PASS** (NULL deref is a real defect, even if
   trigger is edge-case)
3. Important issue? **PASS** (kernel oops in integrity verification —
   HIGH/CRITICAL)
4. Small and contained? **PASS** (4 lines, one function)
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS**

### Step 9.3: Exception categories
**Record:** None (not a quirk, device ID, or build fix).

### Step 9.4: Decision rationale

For **linux-6.18.y** specifically: the vulnerable code is present, the
fix is minimal and obviously correct, and a NULL dereference in the
IMA/EVM signature path is exactly the kind of security-subsystem defect
stable trees should fix. While the trigger may be uncommon with today’s
RSA/ECDSA-only keyrings, the kernel already acknowledges that asymmetric
keys can lack a public-key payload (`restrict.c`), and this path lacked
the corresponding guard. The patch is independent of the ML-DSA feature
commits and safe to backport alone.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from user query and
  spinics/openwall
- **[Phase 2]** Read `security/integrity/digsig_asymmetric.c`; confirmed
  4-line NULL check at `asymmetric_key_public_key()` call site
- **[Phase 2]** Read `include/keys/asymmetric-type.h`; confirmed
  `asymmetric_key_public_key()` returns `key->payload.data[asym_crypto]`
  with no NULL guarantee
- **[Phase 3]** `git describe HEAD` → `v6.18.43`; Makefile VERSION
  6.18.43
- **[Phase 3]** `git blame -L 108,115
  security/integrity/digsig_asymmetric.c` → `6bda50f4333fa`
- **[Phase 3]** `git show 7b923c78b50d:...` → buggy code at merge-base
- **[Phase 3]** `git branch` → detached from `stable/linux-6.18.y`
- **[Phase 4]** spinics/openwall: found v3 1/4 and 0/4; v3 added patches
  per Mimi’s comments
- **[Phase 4]** `b4 shazam` — message-id not found; `b4 dig -c` not run
  (commit absent locally)
- **[Phase 4]** lore.kernel.org — blocked (bot protection)
- **[Phase 4]** Web search — commit `c93a5f0`, integrity-v7.2 pull
  confirmed
- **[Phase 5]** `grep asymmetric_verify` — callers in `digsig.c`,
  `ima_appraise.c`, `evm_main.c`
- **[Phase 5]** Read `crypto/asymmetric_keys/restrict.c` — `!pkey`
  checks at lines 141 and 183
- **[Phase 5]** Read `crypto/asymmetric_keys/signature.c` —
  `verify_signature()` checks `!key->payload.data[0]` but only after
  `asymmetric_verify()` would crash
- **[Phase 6]** Confirmed NULL check absent in current tree at lines
  110–111
- **[Phase 6]** Read `ima_appraise.c` lines 335–338 — sig v3 rejected
  before `integrity_digsig_verify()`
- **[Phase 8]** `grep mldsa` in `crypto/asymmetric_keys` — no ML-DSA
  support in this tree
- **UNVERIFIED:** Exact Mimi Zohar review text (follow-up to v2 on
  spinics not fetched); no production crash report

**YES**The background history search finished. In this
`stable/linux-6.18.y` checkout, `digsig_asymmetric.c` and the
`asymmetric_verify()` path without the NULL check both trace back to
commit `6bda50f4333fa` (Nov 29, 2025), when that file was added. The
vulnerable code is present in the current v6.18.43 tree, so the backport
analysis stands: **YES**.

 security/integrity/digsig_asymmetric.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
index 457c0a396caf3..17219424a34dd 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -108,6 +108,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
 	pks.hash_algo = hash_algo_name[hdr->hash_algo];
 
 	pk = asymmetric_key_public_key(key);
+	if (!pk) {
+		ret = -ENOKEY;
+		goto out;
+	}
 	pks.pkey_algo = pk->pkey_algo;
 	if (!strcmp(pk->pkey_algo, "rsa")) {
 		pks.encoding = "pkcs1";
-- 
2.53.0