AI Trajectory

null

{
  "EnableConfigs": [
    "CRASH_ZEROIZE",
    "CRASH_DUMP",
    "SECRETMEM",
    "KEYS",
    "BIG_KEYS",
    "ENCRYPTED_KEYS",
    "TRUSTED_KEYS"
  ],
  "FocusSymbols": [
    "crash_zeroize",
    "secretmem_crash_zeroize",
    "key_crash_zeroize",
    "big_key_zeroize",
    "encrypted_zeroize",
    "trusted_zeroize",
    "user_zeroize"
  ],
  "Reasoning": "The patch introduces a new feature to zeroize sensitive secrets (keys and secretmem) during a kernel panic/crash. This is functional code that executes when a crash kernel is loaded and a panic occurs. Fuzzing can help ensure these teardown paths do not introduce secondary faults or deadlocks.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 5b447f1d7ca1606154165fcd0ea43d1dcbaa0e39\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Aug 2 04:00:36 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/of/kexec.c b/drivers/of/kexec.c\nindex 029903b986cbd..36635f6cb9009 100644\n--- a/drivers/of/kexec.c\n+++ b/drivers/of/kexec.c\n@@ -24,7 +24,7 @@\n \n /*\n  * Additional space needed for the FDT buffer so that we can add initrd,\n- * bootargs, kaslr-seed, rng-seed, useable-memory-range and elfcorehdr.\n+ * bootargs, kaslr-seed, rng-seed, usable-memory-range and elfcorehdr.\n  */\n #define FDT_EXTRA_SPACE 0x1000\n \ndiff --git a/include/linux/crash_core.h b/include/linux/crash_core.h\nindex bc087124cd78e..5c7207c0bba14 100644\n--- a/include/linux/crash_core.h\n+++ b/include/linux/crash_core.h\n@@ -5,6 +5,7 @@\n #include \u003clinux/linkage.h\u003e\n #include \u003clinux/elfcore.h\u003e\n #include \u003clinux/elf.h\u003e\n+#include \u003clinux/notifier.h\u003e\n \n struct kimage;\n \n@@ -34,6 +35,10 @@ static inline void arch_kexec_protect_crashkres(void) { }\n static inline void arch_kexec_unprotect_crashkres(void) { }\n #endif\n \n+#ifdef CONFIG_CRASH_ZEROIZE\n+extern struct atomic_notifier_head crash_zeroize_notifier_list;\n+#endif\n+\n #ifndef arch_crash_handle_hotplug_event\n static inline void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { }\n #endif\ndiff --git a/include/linux/key-type.h b/include/linux/key-type.h\nindex bb97bd3e5af4f..ff0944ce368f9 100644\n--- a/include/linux/key-type.h\n+++ b/include/linux/key-type.h\n@@ -122,6 +122,15 @@ struct key_type {\n \t/* clear the data from a key (optional) */\n \tvoid (*destroy)(struct key *key);\n \n+\t/* scrub the key material without free'ing (optional)\n+\t * - used from CONFIG_CRASH_ZEROIZE during panic to keep keys out of\n+\t *   crash dumps\n+\t * - called from the panic path with other CPUs stopped and preemption\n+\t *   disabled\n+\t * - must not sleep, allocate, free or take locks\n+\t */\n+\tvoid (*zeroize)(struct key *key);\n+\n \t/* describe a key */\n \tvoid (*describe)(const struct key *key, struct seq_file *p);\n \ndiff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec\nindex 15632358bcf71..92ab0a69c8ec6 100644\n--- a/kernel/Kconfig.kexec\n+++ b/kernel/Kconfig.kexec\n@@ -179,4 +179,12 @@ config CRASH_MAX_MEMORY_RANGES\n \t  the computation behind the value provided through the\n \t  /sys/kernel/crash_elfcorehdr_size attribute.\n \n+config CRASH_ZEROIZE\n+\tbool \"Zeroize secrets on panic\"\n+\tdepends on CRASH_DUMP\n+\thelp\n+\t  Wipe secrets (e.g. kernel keyring and memfd_secret pages) on crash or panic.\n+\n+\t  If unsure, say N.\n+\n endmenu\ndiff --git a/kernel/crash_core.c b/kernel/crash_core.c\nindex 2b36aa9fade06..d3a7763e27599 100644\n--- a/kernel/crash_core.c\n+++ b/kernel/crash_core.c\n@@ -23,6 +23,7 @@\n #include \u003clinux/objtool.h\u003e\n #include \u003clinux/delay.h\u003e\n #include \u003clinux/panic.h\u003e\n+#include \u003clinux/timekeeping.h\u003e\n \n #include \u003casm/page.h\u003e\n #include \u003casm/sections.h\u003e\n@@ -33,6 +34,22 @@\n /* Per cpu memory for storing cpu states in case of system crash. */\n note_buf_t __percpu *crash_notes;\n \n+#ifdef CONFIG_CRASH_ZEROIZE\n+ATOMIC_NOTIFIER_HEAD(crash_zeroize_notifier_list);\n+EXPORT_SYMBOL_GPL(crash_zeroize_notifier_list);\n+\n+static void crash_zeroize(void)\n+{\n+\tktime_t zeroize_start = ktime_get();\n+\n+\tpr_info(\"Wiping sensitive secrets...\\n\");\n+\tatomic_notifier_call_chain(\u0026crash_zeroize_notifier_list, 0, NULL);\n+\tpr_info(\"Done in %lld us\\n\", ktime_us_delta(ktime_get(), zeroize_start));\n+}\n+#else\n+static inline void crash_zeroize(void) { }\n+#endif /* CONFIG_CRASH_ZEROIZE */\n+\n /* time to wait for possible DMA to finish before starting the kdump kernel\n  * when a CMA reservation is used\n  */\n@@ -142,6 +159,7 @@ void __noclone __crash_kexec(struct pt_regs *regs)\n \t\t\tcrash_save_vmcoreinfo();\n \t\t\tmachine_crash_shutdown(\u0026fixed_regs);\n \t\t\tcrash_cma_clear_pending_dma();\n+\t\t\tcrash_zeroize();\n \t\t\tmachine_kexec(kexec_crash_image);\n \t\t}\n \t\tkexec_unlock();\ndiff --git a/mm/secretmem.c b/mm/secretmem.c\nindex d29865075b6ea..53f629d6633c1 100644\n--- a/mm/secretmem.c\n+++ b/mm/secretmem.c\n@@ -13,9 +13,11 @@\n #include \u003clinux/bitops.h\u003e\n #include \u003clinux/printk.h\u003e\n #include \u003clinux/pagemap.h\u003e\n+#include \u003clinux/notifier.h\u003e\n #include \u003clinux/syscalls.h\u003e\n #include \u003clinux/pseudo_fs.h\u003e\n #include \u003clinux/secretmem.h\u003e\n+#include \u003clinux/crash_core.h\u003e\n #include \u003clinux/set_memory.h\u003e\n #include \u003clinux/sched/signal.h\u003e\n \n@@ -187,6 +189,50 @@ static const struct inode_operations secretmem_iops = {\n \n static struct vfsmount *secretmem_mnt;\n \n+#ifdef CONFIG_CRASH_ZEROIZE\n+/* Called far into vpanic from crash_core.c with other CPUs stopped and\n+ * preemption disabled\n+ */\n+static int secretmem_crash_zeroize(struct notifier_block *nb, unsigned long\n+\t\taction, void *data)\n+{\n+\tstruct super_block *sb;\n+\tstruct inode *inode;\n+\n+\tif (!secretmem_mnt)\n+\t\treturn NOTIFY_DONE;\n+\tsb = secretmem_mnt-\u003emnt_sb;\n+\n+\t/* If the list was modified in the exact moment we panic'ed, it might be\n+\t * in an inconsistent state that would be unsafe to iterate. If we can't\n+\t * get the lock, too bad, that's all we can do here.\n+\t */\n+\tif (!spin_trylock(\u0026sb-\u003es_inode_list_lock)) {\n+\t\tpr_crit(\"crash_zeroize: can't acquire secretmem superblock lock.\\n\"\n+\t\t\t \"crash_zeroize: skipping zeroizing secretmem.\\n\");\n+\t\treturn NOTIFY_DONE;\n+\t}\n+\n+\tlist_for_each_entry(inode, \u0026sb-\u003es_inodes, i_sb_list) {\n+\t\tXA_STATE(xas, \u0026inode-\u003ei_mapping-\u003ei_pages, 0);\n+\t\tstruct folio *folio;\n+\n+\t\t/* no need for locks if we're burning down the house :) */\n+\t\txas_for_each(\u0026xas, folio, ULONG_MAX) {\n+\t\t\tif (xas_retry(\u0026xas, folio) || xa_is_value(folio))\n+\t\t\t\tcontinue;\n+\t\t\tinode-\u003ei_mapping-\u003ea_ops-\u003efree_folio(folio);\n+\t\t}\n+\t}\n+\t/* off to kexec()! */\n+\treturn NOTIFY_DONE;\n+}\n+\n+static struct notifier_block secretmem_zeroize_nb = {\n+\t.notifier_call = secretmem_crash_zeroize\n+};\n+#endif /* CONFIG_CRASH_ZEROIZE */\n+\n static struct file *secretmem_file_create(unsigned long flags)\n {\n \tstruct file *file;\n@@ -263,6 +309,10 @@ static int __init secretmem_init(void)\n \tif (IS_ERR(secretmem_mnt))\n \t\treturn PTR_ERR(secretmem_mnt);\n \n+#ifdef CONFIG_CRASH_ZEROIZE\n+\tatomic_notifier_chain_register(\u0026crash_zeroize_notifier_list, \u0026secretmem_zeroize_nb);\n+#endif\n+\n \treturn 0;\n }\n fs_initcall(secretmem_init);\ndiff --git a/security/keys/big_key.c b/security/keys/big_key.c\nindex 268f702df380e..ad8537dda70fa 100644\n--- a/security/keys/big_key.c\n+++ b/security/keys/big_key.c\n@@ -35,6 +35,8 @@ struct big_key_payload {\n  */\n #define BIG_KEY_FILE_THRESHOLD (sizeof(struct inode) + sizeof(struct dentry))\n \n+static void big_key_zeroize(struct key *key);\n+\n /*\n  * big_key defined keys take an arbitrary string as the description and an\n  * arbitrary blob of data as the payload\n@@ -46,6 +48,7 @@ struct key_type key_type_big_key = {\n \t.instantiate\t\t= generic_key_instantiate,\n \t.revoke\t\t\t= big_key_revoke,\n \t.destroy\t\t= big_key_destroy,\n+\t.zeroize\t\t= big_key_zeroize,\n \t.describe\t\t= big_key_describe,\n \t.read\t\t\t= big_key_read,\n \t.update\t\t\t= big_key_update,\n@@ -279,6 +282,18 @@ long big_key_read(const struct key *key, char *buffer, size_t buflen)\n \treturn ret;\n }\n \n+static void big_key_zeroize(struct key *key)\n+{\n+\tstruct big_key_payload *payload = to_big_key_payload(key-\u003epayload);\n+\n+\tif (payload-\u003edata) {\n+\t\tif (payload-\u003elength \u003e BIG_KEY_FILE_THRESHOLD)\n+\t\t\tmemzero_explicit(payload-\u003edata, CHACHA20POLY1305_KEY_SIZE);\n+\t\telse\n+\t\t\tmemzero_explicit(payload-\u003edata, payload-\u003elength);\n+\t}\n+}\n+\n /*\n  * Register key type\n  */\ndiff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c\nindex 59cb77b237b36..9f56fa9b4aaf4 100644\n--- a/security/keys/encrypted-keys/encrypted.c\n+++ b/security/keys/encrypted-keys/encrypted.c\n@@ -970,11 +970,23 @@ static void encrypted_destroy(struct key *key)\n \tkfree_sensitive(key-\u003epayload.data[0]);\n }\n \n+static void encrypted_zeroize(struct key *key)\n+{\n+\tstruct encrypted_key_payload *epayload = key-\u003epayload.data[0];\n+\n+\tif (!epayload)\n+\t\treturn;\n+\n+\tmemzero_explicit(epayload-\u003epayload_data,\n+\t\t\t epayload-\u003epayload_datalen + epayload-\u003edatablob_len);\n+}\n+\n struct key_type key_type_encrypted = {\n \t.name = \"encrypted\",\n \t.instantiate = encrypted_instantiate,\n \t.update = encrypted_update,\n \t.destroy = encrypted_destroy,\n+\t.zeroize = encrypted_zeroize,\n \t.describe = user_describe,\n \t.read = encrypted_read,\n };\ndiff --git a/security/keys/key.c b/security/keys/key.c\nindex b34a64d81d47a..5673dcc8c5d23 100644\n--- a/security/keys/key.c\n+++ b/security/keys/key.c\n@@ -12,6 +12,7 @@\n #include \u003clinux/slab.h\u003e\n #include \u003clinux/security.h\u003e\n #include \u003clinux/workqueue.h\u003e\n+#include \u003clinux/crash_core.h\u003e\n #include \u003clinux/random.h\u003e\n #include \u003clinux/err.h\u003e\n #include \"internal.h\"\n@@ -1268,6 +1269,44 @@ void unregister_key_type(struct key_type *ktype)\n }\n EXPORT_SYMBOL(unregister_key_type);\n \n+#ifdef CONFIG_CRASH_ZEROIZE\n+/* Called far into vpanic from crash_core.c with other CPUs stopped and\n+ * preemption disabled\n+ */\n+static int key_crash_zeroize(struct notifier_block *nb, unsigned long action,\n+\t\tvoid *data)\n+{\n+\tstruct rb_node *node;\n+\n+\t/* If we can't acquire the lock, the rbtree might be in an inconsistent\n+\t * state. That's all we can do then, as there's no point to waiting\n+\t * at this stage.\n+\t */\n+\tif (!spin_trylock(\u0026key_serial_lock)) {\n+\t\tpr_crit(\"crash_zeroize: can't acquire key_serial_lock. skipping keyrings.\\n\");\n+\t\treturn NOTIFY_DONE;\n+\t}\n+\n+\tfor (node = rb_first(\u0026key_serial_tree); node; node = rb_next(node)) {\n+\t\tstruct key *key = rb_entry(node, struct key, serial_node);\n+\n+\t\tif (key-\u003etype == \u0026key_type_keyring ||\n+\t\t    key-\u003estate == KEY_IS_UNINSTANTIATED)\n+\t\t\tcontinue;\n+\n+\t\t/* custom zeroize since free'ing isn't safe at this point */\n+\t\tif (key-\u003etype-\u003ezeroize)\n+\t\t\tkey-\u003etype-\u003ezeroize(key);\n+\t}\n+\t/* off to kexec()! */\n+\treturn NOTIFY_DONE;\n+}\n+\n+static struct notifier_block key_crash_zeroize_nb = {\n+\t.notifier_call = key_crash_zeroize\n+};\n+#endif /* CONFIG_CRASH_ZEROIZE */\n+\n /*\n  * Initialise the key management state.\n  */\n@@ -1290,4 +1329,9 @@ void __init key_init(void)\n \n \trb_insert_color(\u0026root_key_user.node,\n \t\t\t\u0026key_user_tree);\n+\n+#ifdef CONFIG_CRASH_ZEROIZE\n+\tatomic_notifier_chain_register(\u0026crash_zeroize_notifier_list,\n+\t\t\t\u0026key_crash_zeroize_nb);\n+#endif\n }\ndiff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c\nindex 0509d9955f2a6..f159faeafe23a 100644\n--- a/security/keys/trusted-keys/trusted_core.c\n+++ b/security/keys/trusted-keys/trusted_core.c\n@@ -325,11 +325,25 @@ static void trusted_destroy(struct key *key)\n \tkfree_sensitive(key-\u003epayload.data[0]);\n }\n \n+static void trusted_zeroize(struct key *key)\n+{\n+\tstruct trusted_key_payload *p = key-\u003epayload.data[0];\n+\n+\tif (!p)\n+\t\treturn;\n+\n+\tmemzero_explicit(p-\u003ekey, sizeof(p-\u003ekey));\n+\tmemzero_explicit(p-\u003eblob, sizeof(p-\u003eblob));\n+\tp-\u003ekey_len = 0;\n+\tp-\u003eblob_len = 0;\n+}\n+\n struct key_type key_type_trusted = {\n \t.name = \"trusted\",\n \t.instantiate = trusted_instantiate,\n \t.update = trusted_update,\n \t.destroy = trusted_destroy,\n+\t.zeroize = trusted_zeroize,\n \t.describe = user_describe,\n \t.read = trusted_read,\n };\ndiff --git a/security/keys/user_defined.c b/security/keys/user_defined.c\nindex 6f88b507f9279..ade95dc2481df 100644\n--- a/security/keys/user_defined.c\n+++ b/security/keys/user_defined.c\n@@ -15,6 +15,7 @@\n #include \"internal.h\"\n \n static int logon_vet_description(const char *desc);\n+static void user_zeroize(struct key *key);\n \n /*\n  * user defined keys take an arbitrary string as the description and an\n@@ -28,6 +29,7 @@ struct key_type key_type_user = {\n \t.update\t\t\t= user_update,\n \t.revoke\t\t\t= user_revoke,\n \t.destroy\t\t= user_destroy,\n+\t.zeroize\t\t= user_zeroize,\n \t.describe\t\t= user_describe,\n \t.read\t\t\t= user_read,\n };\n@@ -48,6 +50,7 @@ struct key_type key_type_logon = {\n \t.update\t\t\t= user_update,\n \t.revoke\t\t\t= user_revoke,\n \t.destroy\t\t= user_destroy,\n+\t.zeroize\t\t= user_zeroize,\n \t.describe\t\t= user_describe,\n \t.vet_description\t= logon_vet_description,\n };\n@@ -152,6 +155,14 @@ void user_destroy(struct key *key)\n \n EXPORT_SYMBOL_GPL(user_destroy);\n \n+static void user_zeroize(struct key *key)\n+{\n+\tstruct user_key_payload *upayload = key-\u003epayload.data[0];\n+\n+\tif (upayload)\n+\t\tmemzero_explicit(upayload-\u003edata, upayload-\u003edatalen);\n+}\n+\n /*\n  * describe the user key\n  */\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "CRASH_ZEROIZE",
    "CRASH_DUMP",
    "SECRETMEM",
    "KEYS",
    "BIG_KEYS",
    "ENCRYPTED_KEYS",
    "TRUSTED_KEYS"
  ],
  "FocusSymbols": [
    "crash_zeroize",
    "secretmem_crash_zeroize",
    "key_crash_zeroize",
    "big_key_zeroize",
    "encrypted_zeroize",
    "trusted_zeroize",
    "user_zeroize"
  ],
  "Reasoning": "The patch introduces a new feature to zeroize sensitive secrets (keys and secretmem) during a kernel panic/crash. This is functional code that executes when a crash kernel is loaded and a panic occurs. Fuzzing can help ensure these teardown paths do not introduce secondary faults or deadlocks.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 5b447f1d7ca1606154165fcd0ea43d1dcbaa0e39
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Aug 2 04:00:36 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 029903b986cbd..36635f6cb9009 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -24,7 +24,7 @@
 
 /*
  * Additional space needed for the FDT buffer so that we can add initrd,
- * bootargs, kaslr-seed, rng-seed, useable-memory-range and elfcorehdr.
+ * bootargs, kaslr-seed, rng-seed, usable-memory-range and elfcorehdr.
  */
 #define FDT_EXTRA_SPACE 0x1000
 
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index bc087124cd78e..5c7207c0bba14 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -5,6 +5,7 @@
 #include <linux/linkage.h>
 #include <linux/elfcore.h>
 #include <linux/elf.h>
+#include <linux/notifier.h>
 
 struct kimage;
 
@@ -34,6 +35,10 @@ static inline void arch_kexec_protect_crashkres(void) { }
 static inline void arch_kexec_unprotect_crashkres(void) { }
 #endif
 
+#ifdef CONFIG_CRASH_ZEROIZE
+extern struct atomic_notifier_head crash_zeroize_notifier_list;
+#endif
+
 #ifndef arch_crash_handle_hotplug_event
 static inline void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { }
 #endif
diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index bb97bd3e5af4f..ff0944ce368f9 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -122,6 +122,15 @@ struct key_type {
 	/* clear the data from a key (optional) */
 	void (*destroy)(struct key *key);
 
+	/* scrub the key material without free'ing (optional)
+	 * - used from CONFIG_CRASH_ZEROIZE during panic to keep keys out of
+	 *   crash dumps
+	 * - called from the panic path with other CPUs stopped and preemption
+	 *   disabled
+	 * - must not sleep, allocate, free or take locks
+	 */
+	void (*zeroize)(struct key *key);
+
 	/* describe a key */
 	void (*describe)(const struct key *key, struct seq_file *p);
 
diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index 15632358bcf71..92ab0a69c8ec6 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -179,4 +179,12 @@ config CRASH_MAX_MEMORY_RANGES
 	  the computation behind the value provided through the
 	  /sys/kernel/crash_elfcorehdr_size attribute.
 
+config CRASH_ZEROIZE
+	bool "Zeroize secrets on panic"
+	depends on CRASH_DUMP
+	help
+	  Wipe secrets (e.g. kernel keyring and memfd_secret pages) on crash or panic.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 2b36aa9fade06..d3a7763e27599 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -23,6 +23,7 @@
 #include <linux/objtool.h>
 #include <linux/delay.h>
 #include <linux/panic.h>
+#include <linux/timekeeping.h>
 
 #include <asm/page.h>
 #include <asm/sections.h>
@@ -33,6 +34,22 @@
 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t __percpu *crash_notes;
 
+#ifdef CONFIG_CRASH_ZEROIZE
+ATOMIC_NOTIFIER_HEAD(crash_zeroize_notifier_list);
+EXPORT_SYMBOL_GPL(crash_zeroize_notifier_list);
+
+static void crash_zeroize(void)
+{
+	ktime_t zeroize_start = ktime_get();
+
+	pr_info("Wiping sensitive secrets...\n");
+	atomic_notifier_call_chain(&crash_zeroize_notifier_list, 0, NULL);
+	pr_info("Done in %lld us\n", ktime_us_delta(ktime_get(), zeroize_start));
+}
+#else
+static inline void crash_zeroize(void) { }
+#endif /* CONFIG_CRASH_ZEROIZE */
+
 /* time to wait for possible DMA to finish before starting the kdump kernel
  * when a CMA reservation is used
  */
@@ -142,6 +159,7 @@ void __noclone __crash_kexec(struct pt_regs *regs)
 			crash_save_vmcoreinfo();
 			machine_crash_shutdown(&fixed_regs);
 			crash_cma_clear_pending_dma();
+			crash_zeroize();
 			machine_kexec(kexec_crash_image);
 		}
 		kexec_unlock();
diff --git a/mm/secretmem.c b/mm/secretmem.c
index d29865075b6ea..53f629d6633c1 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -13,9 +13,11 @@
 #include <linux/bitops.h>
 #include <linux/printk.h>
 #include <linux/pagemap.h>
+#include <linux/notifier.h>
 #include <linux/syscalls.h>
 #include <linux/pseudo_fs.h>
 #include <linux/secretmem.h>
+#include <linux/crash_core.h>
 #include <linux/set_memory.h>
 #include <linux/sched/signal.h>
 
@@ -187,6 +189,50 @@ static const struct inode_operations secretmem_iops = {
 
 static struct vfsmount *secretmem_mnt;
 
+#ifdef CONFIG_CRASH_ZEROIZE
+/* Called far into vpanic from crash_core.c with other CPUs stopped and
+ * preemption disabled
+ */
+static int secretmem_crash_zeroize(struct notifier_block *nb, unsigned long
+		action, void *data)
+{
+	struct super_block *sb;
+	struct inode *inode;
+
+	if (!secretmem_mnt)
+		return NOTIFY_DONE;
+	sb = secretmem_mnt->mnt_sb;
+
+	/* If the list was modified in the exact moment we panic'ed, it might be
+	 * in an inconsistent state that would be unsafe to iterate. If we can't
+	 * get the lock, too bad, that's all we can do here.
+	 */
+	if (!spin_trylock(&sb->s_inode_list_lock)) {
+		pr_crit("crash_zeroize: can't acquire secretmem superblock lock.\n"
+			 "crash_zeroize: skipping zeroizing secretmem.\n");
+		return NOTIFY_DONE;
+	}
+
+	list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
+		XA_STATE(xas, &inode->i_mapping->i_pages, 0);
+		struct folio *folio;
+
+		/* no need for locks if we're burning down the house :) */
+		xas_for_each(&xas, folio, ULONG_MAX) {
+			if (xas_retry(&xas, folio) || xa_is_value(folio))
+				continue;
+			inode->i_mapping->a_ops->free_folio(folio);
+		}
+	}
+	/* off to kexec()! */
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block secretmem_zeroize_nb = {
+	.notifier_call = secretmem_crash_zeroize
+};
+#endif /* CONFIG_CRASH_ZEROIZE */
+
 static struct file *secretmem_file_create(unsigned long flags)
 {
 	struct file *file;
@@ -263,6 +309,10 @@ static int __init secretmem_init(void)
 	if (IS_ERR(secretmem_mnt))
 		return PTR_ERR(secretmem_mnt);
 
+#ifdef CONFIG_CRASH_ZEROIZE
+	atomic_notifier_chain_register(&crash_zeroize_notifier_list, &secretmem_zeroize_nb);
+#endif
+
 	return 0;
 }
 fs_initcall(secretmem_init);
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 268f702df380e..ad8537dda70fa 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -35,6 +35,8 @@ struct big_key_payload {
  */
 #define BIG_KEY_FILE_THRESHOLD (sizeof(struct inode) + sizeof(struct dentry))
 
+static void big_key_zeroize(struct key *key);
+
 /*
  * big_key defined keys take an arbitrary string as the description and an
  * arbitrary blob of data as the payload
@@ -46,6 +48,7 @@ struct key_type key_type_big_key = {
 	.instantiate		= generic_key_instantiate,
 	.revoke			= big_key_revoke,
 	.destroy		= big_key_destroy,
+	.zeroize		= big_key_zeroize,
 	.describe		= big_key_describe,
 	.read			= big_key_read,
 	.update			= big_key_update,
@@ -279,6 +282,18 @@ long big_key_read(const struct key *key, char *buffer, size_t buflen)
 	return ret;
 }
 
+static void big_key_zeroize(struct key *key)
+{
+	struct big_key_payload *payload = to_big_key_payload(key->payload);
+
+	if (payload->data) {
+		if (payload->length > BIG_KEY_FILE_THRESHOLD)
+			memzero_explicit(payload->data, CHACHA20POLY1305_KEY_SIZE);
+		else
+			memzero_explicit(payload->data, payload->length);
+	}
+}
+
 /*
  * Register key type
  */
diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
index 59cb77b237b36..9f56fa9b4aaf4 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -970,11 +970,23 @@ static void encrypted_destroy(struct key *key)
 	kfree_sensitive(key->payload.data[0]);
 }
 
+static void encrypted_zeroize(struct key *key)
+{
+	struct encrypted_key_payload *epayload = key->payload.data[0];
+
+	if (!epayload)
+		return;
+
+	memzero_explicit(epayload->payload_data,
+			 epayload->payload_datalen + epayload->datablob_len);
+}
+
 struct key_type key_type_encrypted = {
 	.name = "encrypted",
 	.instantiate = encrypted_instantiate,
 	.update = encrypted_update,
 	.destroy = encrypted_destroy,
+	.zeroize = encrypted_zeroize,
 	.describe = user_describe,
 	.read = encrypted_read,
 };
diff --git a/security/keys/key.c b/security/keys/key.c
index b34a64d81d47a..5673dcc8c5d23 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <linux/security.h>
 #include <linux/workqueue.h>
+#include <linux/crash_core.h>
 #include <linux/random.h>
 #include <linux/err.h>
 #include "internal.h"
@@ -1268,6 +1269,44 @@ void unregister_key_type(struct key_type *ktype)
 }
 EXPORT_SYMBOL(unregister_key_type);
 
+#ifdef CONFIG_CRASH_ZEROIZE
+/* Called far into vpanic from crash_core.c with other CPUs stopped and
+ * preemption disabled
+ */
+static int key_crash_zeroize(struct notifier_block *nb, unsigned long action,
+		void *data)
+{
+	struct rb_node *node;
+
+	/* If we can't acquire the lock, the rbtree might be in an inconsistent
+	 * state. That's all we can do then, as there's no point to waiting
+	 * at this stage.
+	 */
+	if (!spin_trylock(&key_serial_lock)) {
+		pr_crit("crash_zeroize: can't acquire key_serial_lock. skipping keyrings.\n");
+		return NOTIFY_DONE;
+	}
+
+	for (node = rb_first(&key_serial_tree); node; node = rb_next(node)) {
+		struct key *key = rb_entry(node, struct key, serial_node);
+
+		if (key->type == &key_type_keyring ||
+		    key->state == KEY_IS_UNINSTANTIATED)
+			continue;
+
+		/* custom zeroize since free'ing isn't safe at this point */
+		if (key->type->zeroize)
+			key->type->zeroize(key);
+	}
+	/* off to kexec()! */
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block key_crash_zeroize_nb = {
+	.notifier_call = key_crash_zeroize
+};
+#endif /* CONFIG_CRASH_ZEROIZE */
+
 /*
  * Initialise the key management state.
  */
@@ -1290,4 +1329,9 @@ void __init key_init(void)
 
 	rb_insert_color(&root_key_user.node,
 			&key_user_tree);
+
+#ifdef CONFIG_CRASH_ZEROIZE
+	atomic_notifier_chain_register(&crash_zeroize_notifier_list,
+			&key_crash_zeroize_nb);
+#endif
 }
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 0509d9955f2a6..f159faeafe23a 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -325,11 +325,25 @@ static void trusted_destroy(struct key *key)
 	kfree_sensitive(key->payload.data[0]);
 }
 
+static void trusted_zeroize(struct key *key)
+{
+	struct trusted_key_payload *p = key->payload.data[0];
+
+	if (!p)
+		return;
+
+	memzero_explicit(p->key, sizeof(p->key));
+	memzero_explicit(p->blob, sizeof(p->blob));
+	p->key_len = 0;
+	p->blob_len = 0;
+}
+
 struct key_type key_type_trusted = {
 	.name = "trusted",
 	.instantiate = trusted_instantiate,
 	.update = trusted_update,
 	.destroy = trusted_destroy,
+	.zeroize = trusted_zeroize,
 	.describe = user_describe,
 	.read = trusted_read,
 };
diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
index 6f88b507f9279..ade95dc2481df 100644
--- a/security/keys/user_defined.c
+++ b/security/keys/user_defined.c
@@ -15,6 +15,7 @@
 #include "internal.h"
 
 static int logon_vet_description(const char *desc);
+static void user_zeroize(struct key *key);
 
 /*
  * user defined keys take an arbitrary string as the description and an
@@ -28,6 +29,7 @@ struct key_type key_type_user = {
 	.update			= user_update,
 	.revoke			= user_revoke,
 	.destroy		= user_destroy,
+	.zeroize		= user_zeroize,
 	.describe		= user_describe,
 	.read			= user_read,
 };
@@ -48,6 +50,7 @@ struct key_type key_type_logon = {
 	.update			= user_update,
 	.revoke			= user_revoke,
 	.destroy		= user_destroy,
+	.zeroize		= user_zeroize,
 	.describe		= user_describe,
 	.vet_description	= logon_vet_description,
 };
@@ -152,6 +155,14 @@ void user_destroy(struct key *key)
 
 EXPORT_SYMBOL_GPL(user_destroy);
 
+static void user_zeroize(struct key *key)
+{
+	struct user_key_payload *upayload = key->payload.data[0];
+
+	if (upayload)
+		memzero_explicit(upayload->data, upayload->datalen);
+}
+
 /*
  * describe the user key
  */

gemini-3.1-pro-preview

null

null

							input: 6574
							output: 19
							thoughts: 3250
						

**Analysis of the 'CONFIG_CRASH_ZEROIZE' Feature for Fuzzing**

Alright, let's break this down. We have a new feature, `CONFIG_CRASH_ZEROIZE`, designed to zero out sensitive data (secrets, keys, etc.) during a panic or kernel crash. The core of this functionality lies within `kernel/crash_core.c`, specifically the `__crash_kexec` function, which is triggered when `kexec_crash_image` is non-NULL. This indicates the presence of a crash kernel loaded using `kexec_load` or `kexec_file_load` with `KEXEC_ON_CRASH`. This function calls `crash_zeroize()`, which iterates over a list of notifiers registered by subsystems like `secretmem` and `keys`, ultimately zeroing out specific memory regions.

The key question is, can this be effectively fuzzed by syzkaller? Syzkaller's usual workflow avoids panics because they're generally considered bugs, and the fuzzer loses control once a panic occurs (reboots the VM, losing the session). The aim is to find normal kernel bugs. If a panic *does* happen, the fuzzer logs the crash and restarts, effectively not fuzzing the panic handler itself.

The `crash_zeroize` code path is reachable *only* if a crash kernel is loaded *and* a panic is triggered. While syzkaller *could* potentially use `kexec_load` to load a crash kernel and then trigger a panic via SysRq-c or a crafted system call (or by triggering a bug with crash), syzkaller doesn't usually do this. It's not the primary focus. Fuzzing panic handlers is niche because the fuzzer loses control after the panic; this makes effective coverage-guided fuzzing difficult.

The notifiers within this patch are `secretmem_crash_zeroize` and various `key_crash_zeroize` functions. They're executed in the panic context. To fuzz them, we'd need to load a crash kernel, trigger a panic, and ensure secrets or key material are allocated. The prompt also states to exclude certain scenarios like `.remove`, `.shutdown`, etc., that only execute during driver unbinding. This case is similar, because it's only executed on crash.

The prompt, however, focuses on *reachability*, and this is reachable, *even if hard to fuzz*. Code that is explicitly unreachable, or that only executes in unvirtualizable environments, is what is to be excluded.

So, while it is *difficult* to fuzz this path using syzkaller’s current workflow (because it requires deliberate panic triggering and a different setup), it's *technically* reachable. The feature is functional, and this code zeroizes memory for security purposes. Therefore, even though the primary fuzzing benefit is lower, it should be marked as potentially fuzzed because it modifies core kernel logic. Thus, my conclusion is that `WorthFuzzing=true`.

For syzkaller to target this, the following configurations are necessary: `CONFIG_CRASH_ZEROIZE`, `CONFIG_CRASH_DUMP`, `CONFIG_KEXEC_CORE`, and probably `CONFIG_SECRETMEM`, `CONFIG_KEYS`, `CONFIG_ENCRYPTED_KEYS`, `CONFIG_TRUSTED_KEYS` and `CONFIG_BIG_KEYS`.

The potentially interesting symbols for fuzzing are: `crash_zeroize`, `secretmem_crash_zeroize`, `key_crash_zeroize`, `big_key_zeroize`, `encrypted_zeroize`, `trusted_zeroize`, and `user_zeroize`. However, `crash_zeroize` is static so it might be inlined. The others are function pointers.

While the primary goal of syzkaller is to find bugs in *normal* kernel operation, this patch introduces a functional change that can be reached and is security-relevant. I will return `WorthFuzzing=true` with the list of symbols and configs.

{
  "Expression": "config SECRETMEM"
}

{
  "Output": "mm/Kconfig=1338=config MEMFD_CREATE\n--\nmm/Kconfig-1340-\nmm/Kconfig:1341:config SECRETMEM\nmm/Kconfig-1342-\tdefault y\n"
}

gemini-3.1-pro-preview

null

null

							input: 10777
							output: 18
							thoughts: 34
						

Okay, here's my take on those key concepts.

**Verifying Key Security Measures**

Alright, the initial assessment of `SECRETMEM` checks out – that's a good starting point. Now, I need to methodically review the other key areas we discussed: `BIG_KEYS`, `ENCRYPTED_KEYS`, and `TRUSTED_KEYS`. I want to make sure the implementation aligns with best practices and that there are no gaps in the overall security posture. I'll need to dig into the specifics of each to confirm they are configured and operating in the most secure way possible, and that they are appropriately integrated and managed. The goal is a comprehensive and robust security model.

{
  "Expression": "config BIG_KEYS"
}

{
  "Output": "security/keys/Kconfig=43=config PERSISTENT_KEYRINGS\n--\nsecurity/keys/Kconfig-58-\nsecurity/keys/Kconfig:59:config BIG_KEYS\nsecurity/keys/Kconfig-60-\tbool \"Large payload keys\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 11052
							output: 20
							thoughts: 0
						

{
  "Expression": "config ENCRYPTED_KEYS"
}

{
  "Output": "security/keys/Kconfig=82=endif\nsecurity/keys/Kconfig-83-\nsecurity/keys/Kconfig:84:config ENCRYPTED_KEYS\nsecurity/keys/Kconfig-85-\ttristate \"ENCRYPTED KEYS\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 11145
							output: 19
							thoughts: 0
						

{
  "Expression": "config TRUSTED_KEYS"
}

{
  "Output": "security/keys/Kconfig=59=config BIG_KEYS\n--\nsecurity/keys/Kconfig-69-\nsecurity/keys/Kconfig:70:config TRUSTED_KEYS\nsecurity/keys/Kconfig-71-\ttristate \"TRUSTED KEYS\"\n--\nsecurity/keys/trusted-keys/Kconfig=4=config HAVE_TRUSTED_KEYS_DEBUG\n--\nsecurity/keys/trusted-keys/Kconfig-6-\nsecurity/keys/trusted-keys/Kconfig:7:config TRUSTED_KEYS_DEBUG\nsecurity/keys/trusted-keys/Kconfig-8-\tbool \"Debug trusted keys\"\n--\nsecurity/keys/trusted-keys/Kconfig-21-\nsecurity/keys/trusted-keys/Kconfig:22:config TRUSTED_KEYS_TPM\nsecurity/keys/trusted-keys/Kconfig-23-\tbool \"TPM-based trusted keys\"\n--\nsecurity/keys/trusted-keys/Kconfig-40-\nsecurity/keys/trusted-keys/Kconfig:41:config TRUSTED_KEYS_TEE\nsecurity/keys/trusted-keys/Kconfig-42-\tbool \"TEE-based trusted keys\"\n--\nsecurity/keys/trusted-keys/Kconfig-50-\nsecurity/keys/trusted-keys/Kconfig:51:config TRUSTED_KEYS_CAAM\nsecurity/keys/trusted-keys/Kconfig-52-\tbool \"CAAM-based trusted keys\"\n--\nsecurity/keys/trusted-keys/Kconfig-61-\nsecurity/keys/trusted-keys/Kconfig:62:config TRUSTED_KEYS_DCP\nsecurity/keys/trusted-keys/Kconfig-63-\tbool \"DCP-based trusted keys\"\n--\nsecurity/keys/trusted-keys/Kconfig-70-\nsecurity/keys/trusted-keys/Kconfig:71:config TRUSTED_KEYS_PKWM\nsecurity/keys/trusted-keys/Kconfig-72-\tbool \"PKWM-based trusted keys\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 11646
							output: 20
							thoughts: 29
						

Okay, here's my take on those initial thoughts:

**Analyzing Configuration Parameters**

Alright, the `TRUSTED_KEYS` setting appears to be as expected; that seems straightforward. Now, let's pivot and verify the validity of the `CRASH_DUMP` configuration parameter. Is this the specific config we're actually looking for? Need to confirm it's behaving as intended.

{
  "Expression": "config CRASH_DUMP"
}

{
  "Output": "kernel/Kconfig.kexec=89=config KEXEC_JUMP\n--\nkernel/Kconfig.kexec-96-\nkernel/Kconfig.kexec:97:config CRASH_DUMP\nkernel/Kconfig.kexec-98-\tbool \"kernel crash dumps\"\n--\nkernel/Kconfig.kexec=129=config CRASH_DM_CRYPT_CONFIGS\n--\nkernel/Kconfig.kexec-135-\nkernel/Kconfig.kexec:136:config CRASH_DUMP_KUNIT_TEST\nkernel/Kconfig.kexec-137-\ttristate \"Unit Tests for kernel crash dumps\" if !KUNIT_ALL_TESTS\n"
}

gemini-3.1-pro-preview

null

null

							input: 11958
							output: 16
							thoughts: 48
						

Okay, here's my take on those thoughts, framed as my own mental processing:

**Configuration Checklist**

Right, `CRASH_DUMP`, confirmed. That's the correct flag. And good, `CRASH_ZEROIZE` is the new setting to employ.

Now, let's just do a quick scan to make sure we haven't overlooked any other crucial configurations. Aha, yes, we can't forget `KEYS`. We'll definitely need that one for the key management setup. Okay, moving on...

{
  "Expression": "config KEYS"
}

{
  "Output": "drivers/clocksource/Kconfig=242=config NSPIRE_TIMER\n--\ndrivers/clocksource/Kconfig-247-\ndrivers/clocksource/Kconfig:248:config KEYSTONE_TIMER\ndrivers/clocksource/Kconfig-249-\tbool \"Keystone timer driver\" if COMPILE_TEST\n--\ndrivers/irqchip/Kconfig=393=config IRQ_CROSSBAR\n--\ndrivers/irqchip/Kconfig-400-\ndrivers/irqchip/Kconfig:401:config KEYSTONE_IRQ\ndrivers/irqchip/Kconfig-402-\ttristate \"Keystone 2 IRQ controller IP\"\n--\ndrivers/remoteproc/Kconfig=121=config DA8XX_REMOTEPROC\n--\ndrivers/remoteproc/Kconfig-141-\ndrivers/remoteproc/Kconfig:142:config KEYSTONE_REMOTEPROC\ndrivers/remoteproc/Kconfig-143-\ttristate \"Keystone Remoteproc support\"\n--\ndrivers/soc/ti/Kconfig=9=if SOC_TI\ndrivers/soc/ti/Kconfig-10-\ndrivers/soc/ti/Kconfig:11:config KEYSTONE_NAVIGATOR_QMSS\ndrivers/soc/ti/Kconfig-12-\ttristate \"Keystone Queue Manager Sub System\"\n--\ndrivers/soc/ti/Kconfig-22-\ndrivers/soc/ti/Kconfig:23:config KEYSTONE_NAVIGATOR_DMA\ndrivers/soc/ti/Kconfig-24-\ttristate \"TI Keystone Navigator Packet DMA support\"\n--\ndrivers/usb/phy/Kconfig=23=config FSL_USB2_OTG\n--\ndrivers/usb/phy/Kconfig-30-\ndrivers/usb/phy/Kconfig:31:config KEYSTONE_USB_PHY\ndrivers/usb/phy/Kconfig-32-\ttristate \"Keystone USB PHY Driver\"\n--\nsecurity/keys/Kconfig-5-\nsecurity/keys/Kconfig:6:menuconfig KEYS\nsecurity/keys/Kconfig-7-\tbool \"Enable access key retention support\"\n--\nsecurity/keys/Kconfig=24=if KEYS\nsecurity/keys/Kconfig-25-\nsecurity/keys/Kconfig:26:config KEYS_REQUEST_CACHE\nsecurity/keys/Kconfig-27-\tbool \"Enable temporary caching of the last request_key() result\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 12739
							output: 20
							thoughts: 735
						

**My Analysis of Zeroize Function Symbols for Fuzzing**

Okay, so the initial assessment is correct: `KEYS` is definitely the relevant configuration option here. Now, I need to list the symbols that are associated with the zeroize functions. Let's see... I've identified: `crash_zeroize`, `secretmem_crash_zeroize`, `key_crash_zeroize`, `big_key_zeroize`, `encrypted_zeroize`, `trusted_zeroize`, and `user_zeroize`.

Aha! Now I remember the static definitions. `user_zeroize` is static in `security/keys/user_defined.c`, `big_key_zeroize` is static in `security/keys/big_key.c`, `encrypted_zeroize` is static in `security/keys/encrypted-keys/encrypted.c`, `trusted_zeroize` is static in `security/keys/trusted-keys/trusted_core.c`, `secretmem_crash_zeroize` is static in `mm/secretmem.c`, `key_crash_zeroize` is static in `security/keys/key.c`, and finally, `crash_zeroize` is static in `kernel/crash_core.c`.

Right, the prompt is pushing me to prefer non-static, non-inlined API entrypoints. However, these zeroize functions are *used* via function pointers. Their addresses are taken, which means the compiler *won't* inline them. They'll have their own distinct symbol addresses. So, the static declarations aren't a concern here.

Wait, `crash_zeroize` is called directly, but it isn't an internal helper function. I have to think, it *might* be inlined into `__crash_kexec`.

However, the problem says not to include functions which are well-known, and `__crash_kexec` seems well known. So, I will stick to just the zeroize functions.

I've scanned the codebase and there aren't any other functions associated with the panic-time secret wiping logic that need to be listed.

Now, I'm going to double-check my decision on `WorthFuzzing`. The patch introduces new functional logic: wiping secrets on a panic. This is a security feature, triggered primarily by `kexec_load` combined with a panic. It is worth fuzzing to ensure that it doesn't crash in unexpected ways or introduce deadlocks, although it is a panic handler. The spinlock logic is there specifically to avoid deadlocks. This is definitely worth fuzzing. I'll stick with `WorthFuzzing=true`.

So, the configurations and symbols are:

**Configs:**
`CRASH_ZEROIZE`
`CRASH_DUMP`
`SECRETMEM`
`KEYS`
`BIG_KEYS`
`ENCRYPTED_KEYS`
`TRUSTED_KEYS`

**Symbols:**
`crash_zeroize`
`secretmem_crash_zeroize`
`key_crash_zeroize`
`big_key_zeroize`
`encrypted_zeroize`
`trusted_zeroize`
`user_zeroize`

Let's double check... While it's probably not inlined because it is called directly and isn't used as a helper function. I will add `__crash_kexec` just in case, but let me check again to be sure... Let me do a quick scan of `__crash_kexec`... Okay, I'm going to stick to the zeroize functions.

{
  "Expression": "static void crash_zeroize"
}

{
  "Output": "kernel/crash_core.c=39=EXPORT_SYMBOL_GPL(crash_zeroize_notifier_list);\nkernel/crash_core.c-40-\nkernel/crash_core.c:41:static void crash_zeroize(void)\nkernel/crash_core.c-42-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 14355
							output: 193
							thoughts: 29
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**My Processing Pipeline**

Right, so I'm looking at this data, and the immediate impression is that it's essentially a fixed snapshot – static. It could be embedded directly within the surrounding context (inlined), but from my perspective, that's not critical. The important thing is its immutability at this stage. I don't need to worry about external dependencies or dynamic updating for the next step.

My next operation will be to use a designated function or method. I'll invoke, or call,  `set-results`. This function likely handles the core process of integrating the static data, the immutable data,  into the rest of the current state and then updating the working results. This could involve anything from simply assigning the data to a variable, caching the result, or passing it to the next operation in a bigger pipeline. The actual implementation specifics of `set-results` are not defined in the current context, only its expected purpose. The current focus is to get the static input into the system.

{
  "EnableConfigs": [
    "CRASH_ZEROIZE",
    "CRASH_DUMP",
    "SECRETMEM",
    "KEYS",
    "BIG_KEYS",
    "ENCRYPTED_KEYS",
    "TRUSTED_KEYS"
  ],
  "FocusSymbols": [
    "crash_zeroize",
    "secretmem_crash_zeroize",
    "key_crash_zeroize",
    "big_key_zeroize",
    "encrypted_zeroize",
    "trusted_zeroize",
    "user_zeroize"
  ],
  "Reasoning": "The patch introduces a new feature to zeroize sensitive secrets (keys and secretmem) during a kernel panic/crash. This is functional code that executes when a crash kernel is loaded and a panic occurs. Fuzzing can help ensure these teardown paths do not introduce secondary faults or deadlocks.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "CRASH_ZEROIZE",
    "CRASH_DUMP",
    "SECRETMEM",
    "KEYS",
    "BIG_KEYS",
    "ENCRYPTED_KEYS",
    "TRUSTED_KEYS"
  ],
  "FocusSymbols": [
    "crash_zeroize",
    "secretmem_crash_zeroize",
    "key_crash_zeroize",
    "big_key_zeroize",
    "encrypted_zeroize",
    "trusted_zeroize",
    "user_zeroize"
  ],
  "Reasoning": "The patch introduces a new feature to zeroize sensitive secrets (keys and secretmem) during a kernel panic/crash. This is functional code that executes when a crash kernel is loaded and a panic occurs. Fuzzing can help ensure these teardown paths do not introduce secondary faults or deadlocks.",
  "WorthFuzzing": true
}