AI Trajectory

null

{
  "EnableConfigs": [
    "DEBUG_KMEMLEAK"
  ],
  "FocusSymbols": [
    "__kmemleak_scan",
    "confirm_leak",
    "kmemleak_scan"
  ],
  "Reasoning": "The patch modifies the memory leak detection logic in kmemleak, introducing a new parameter `min_unref_scans` and changing how objects are confirmed as leaks. This is functional kernel code that can be reached via the kmemleak scan thread or debugfs interface.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit bd0f857b513eb98bdc9c241aac503828600ac52a\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Jul 13 14:45:18 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst\nindex 7d784e03f3f9d5..a8a83bc69ceb88 100644\n--- a/Documentation/dev-tools/kmemleak.rst\n+++ b/Documentation/dev-tools/kmemleak.rst\n@@ -198,6 +198,14 @@ systems, because of pointers temporarily stored in CPU registers or\n stacks. Kmemleak defines MSECS_MIN_AGE (defaulting to 1000) representing\n the minimum age of an object to be reported as a memory leak.\n \n+The ``min_unref_scans`` module parameter (default 1) requires an object to\n+be seen unreferenced in that many consecutive scans before it is reported.\n+Keeping it at 1 preserves the historical behaviour; higher values filter\n+the transient false positives described above, at the cost of delaying\n+genuine reports by up to that many scans. It can be set at boot with\n+``kmemleak.min_unref_scans=\u003cn\u003e`` or at run-time via\n+``/sys/module/kmemleak/parameters/min_unref_scans``.\n+\n Limitations and Drawbacks\n -------------------------\n \ndiff --git a/mm/kmemleak.c b/mm/kmemleak.c\nindex e96e9efd19b0d9..85f18b17e79c4e 100644\n--- a/mm/kmemleak.c\n+++ b/mm/kmemleak.c\n@@ -151,6 +151,8 @@ struct kmemleak_object {\n \tint min_count;\n \t/* the total number of pointers found pointing to this object */\n \tint count;\n+\t/* consecutive scans the object has been seen unreferenced */\n+\tunsigned int unref_scans;\n \t/* checksum for detecting modified objects */\n \tu32 checksum;\n \tdepot_stack_handle_t trace_handle;\n@@ -175,6 +177,8 @@ struct kmemleak_object {\n #define OBJECT_PHYS\t\t(1 \u003c\u003c 4)\n /* flag set for per-CPU pointers */\n #define OBJECT_PERCPU\t\t(1 \u003c\u003c 5)\n+/* flag set on an object left unreferenced by the full scan, pending confirmation */\n+#define OBJECT_SUSPECT\t\t(1 \u003c\u003c 6)\n \n /* set when __remove_object() called */\n #define DELSTATE_REMOVED\t(1 \u003c\u003c 0)\n@@ -232,9 +236,14 @@ static unsigned long max_percpu_addr;\n static struct task_struct *scan_thread;\n /* used to avoid reporting of recently allocated objects */\n static unsigned long jiffies_min_age;\n+/* consecutive scans an object must stay unreferenced before reporting */\n+static unsigned int min_unref_scans = 1;\n+module_param(min_unref_scans, uint, 0644);\n static unsigned long jiffies_last_scan;\n /* delay between automatic memory scannings */\n static unsigned long jiffies_scan_wait;\n+/* number of objects flagged OBJECT_SUSPECT during the current scan */\n+static int nr_suspects;\n /* enables or disables the task stacks scanning */\n static int kmemleak_stack_scan = 1;\n /* protects the memory scanning, parameters and debug/kmemleak file access */\n@@ -688,6 +697,7 @@ static struct kmemleak_object *__alloc_object(gfp_t gfp)\n \tobject-\u003eexcess_ref = 0;\n \tobject-\u003ecount = 0;\t\t\t/* white color initially */\n \tobject-\u003echecksum = ~0;\n+\tobject-\u003eunref_scans = 0;\n \tobject-\u003edel_state = 0;\n \n \t/* task information */\n@@ -1440,6 +1450,11 @@ static void update_refs(struct kmemleak_object *object)\n \t */\n \tobject-\u003ecount++;\n \tif (color_gray(object)) {\n+\t\t/* referenced after all, no longer a suspect */\n+\t\tif (object-\u003eflags \u0026 OBJECT_SUSPECT) {\n+\t\t\tobject-\u003eflags \u0026= ~OBJECT_SUSPECT;\n+\t\t\tnr_suspects--;\n+\t\t}\n \t\t/* put_object() called when removing from gray_list */\n \t\tWARN_ON(!get_object(object));\n \t\tlist_add_tail(\u0026object-\u003egray_list, \u0026gray_list);\n@@ -1844,16 +1859,16 @@ static void dedup_flush(struct xarray *dedup)\n  * kernel's standard allocators. This function must be called with the\n  * scan_mutex held.\n  */\n-static void kmemleak_scan(void)\n+static int __kmemleak_scan(bool full)\n {\n \tstruct kmemleak_object *object;\n \tstruct zone *zone;\n \tint __maybe_unused i;\n-\tstruct xarray dedup;\n-\tint new_leaks = 0;\n \tint stop = 0;\n \n \tjiffies_last_scan = jiffies;\n+\tif (full)\n+\t\tnr_suspects = 0;\n \n \t/* prepare the kmemleak_object's */\n \trcu_read_lock();\n@@ -1881,8 +1896,13 @@ static void kmemleak_scan(void)\n \t\t\t\t__paint_it(object, KMEMLEAK_BLACK);\n \t\t}\n \n+\t\t/* referenced last scan: restart the unreferenced run */\n+\t\tif (!color_white(object))\n+\t\t\tobject-\u003eunref_scans = 0;\n \t\t/* reset the reference count (whiten the object) */\n \t\tobject-\u003ecount = 0;\n+\t\tif (full)\n+\t\t\tobject-\u003eflags \u0026= ~OBJECT_SUSPECT;\n \t\tif (color_gray(object) \u0026\u0026 get_object(object))\n \t\t\tlist_add_tail(\u0026object-\u003egray_list, \u0026gray_list);\n \n@@ -1950,6 +1970,10 @@ static void kmemleak_scan(void)\n scan_gray:\n \tscan_gray_list();\n \n+\t/* a confirmation scan does not look for modified objects */\n+\tif (!full)\n+\t\treturn nr_suspects;\n+\n \t/*\n \t * Check for new or unreferenced objects modified since the previous\n \t * scan and color them gray until the next scan.\n@@ -1972,6 +1996,11 @@ static void kmemleak_scan(void)\n \t\t\t/* color it gray temporarily */\n \t\t\tobject-\u003ecount = object-\u003emin_count;\n \t\t\tlist_add_tail(\u0026object-\u003egray_list, \u0026gray_list);\n+\t\t} else if (unreferenced_object(object) \u0026\u0026\n+\t\t\t   !(object-\u003eflags \u0026 OBJECT_REPORTED)) {\n+\t\t\t/* flag the objects left unreferenced by this scan */\n+\t\t\tobject-\u003eflags |= OBJECT_SUSPECT;\n+\t\t\tnr_suspects++;\n \t\t}\n \t\traw_spin_unlock_irq(\u0026object-\u003elock);\n \t}\n@@ -1982,12 +2011,62 @@ static void kmemleak_scan(void)\n \t */\n \tscan_gray_list();\n \n+\treturn nr_suspects;\n+}\n+\n+/*\n+ * Promote a suspected object to a reported leak once it has stayed\n+ * unreferenced for min_unref_scans consecutive scans. Called with\n+ * object-\u003elock held; returns true when the object is newly reported.\n+ */\n+static bool confirm_leak(struct kmemleak_object *object)\n+{\n+\tif (!unreferenced_object(object) ||\n+\t    !(object-\u003eflags \u0026 OBJECT_SUSPECT) ||\n+\t    (object-\u003eflags \u0026 OBJECT_REPORTED))\n+\t\treturn false;\n+\n+\tobject-\u003eunref_scans += 1;\n+\tif (object-\u003eunref_scans \u003c min_unref_scans)\n+\t\treturn false;\n+\n+\tobject-\u003eflags |= OBJECT_REPORTED;\n+\treturn true;\n+}\n+\n+/*\n+ * Scan the memory and report the unreferenced objects as leaks. Must be\n+ * called with the scan_mutex held.\n+ */\n+static void kmemleak_scan(void)\n+{\n+\tstruct kmemleak_object *object;\n+\tstruct xarray dedup;\n+\tint new_leaks = 0;\n+\n+\t/*\n+\t * Full scan. Objects left unreferenced are flagged OBJECT_SUSPECT and\n+\t * counted in the return value; nothing to confirm or report otherwise.\n+\t */\n+\tif (!__kmemleak_scan(true))\n+\t\treturn;\n+\n \t/*\n \t * If scanning was stopped do not report any new unreferenced objects.\n \t */\n \tif (scan_should_stop())\n \t\treturn;\n \n+\t/*\n+\t * A live object whose only reference is moved by, for example, a\n+\t * concurrent RCU update can be missed for one scan and reported as a\n+\t * transient false positive. Scan again and only report the objects\n+\t * left unreferenced (still flagged OBJECT_SUSPECT) by both scans.\n+\t */\n+\t__kmemleak_scan(false);\n+\tif (scan_should_stop())\n+\t\treturn;\n+\n \t/*\n \t * Scanning result reporting. When verbose printing is enabled, dedupe\n \t * by stackdepot trace_handle so each unique backtrace is logged once\n@@ -2014,9 +2093,8 @@ static void kmemleak_scan(void)\n \t\traw_spin_lock_irq(\u0026object-\u003elock);\n \t\ttrace_handle = 0;\n \t\tdedup_print = false;\n-\t\tif (unreferenced_object(object) \u0026\u0026\n-\t\t    !(object-\u003eflags \u0026 OBJECT_REPORTED)) {\n-\t\t\tobject-\u003eflags |= OBJECT_REPORTED;\n+\n+\t\tif (confirm_leak(object)) {\n \t\t\tif (kmemleak_verbose) {\n \t\t\t\ttrace_handle = object-\u003etrace_handle;\n \t\t\t\tdedup_print = true;\ndiff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile\nindex ed321ae709dacf..786b1d73d93b0a 100644\n--- a/tools/testing/selftests/mm/Makefile\n+++ b/tools/testing/selftests/mm/Makefile\n@@ -150,6 +150,7 @@ TEST_PROGS += ksft_gup_test.sh\n TEST_PROGS += ksft_hmm.sh\n TEST_PROGS += ksft_hugetlb.sh\n TEST_PROGS += ksft_hugevm.sh\n+TEST_PROGS += ksft_kmemleak_confirm.sh\n TEST_PROGS += ksft_kmemleak_dedup.sh\n TEST_PROGS += ksft_ksm.sh\n TEST_PROGS += ksft_ksm_numa.sh\ndiff --git a/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh b/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh\nnew file mode 100755\nindex 00000000000000..3a8576e835c8d1\n--- /dev/null\n+++ b/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh\n@@ -0,0 +1,132 @@\n+#!/bin/bash\n+# SPDX-License-Identifier: GPL-2.0\n+#\n+# Functional test for kmemleak's N-consecutive-scan leak confirmation\n+# (the min_unref_scans module parameter).\n+#\n+# kmemleak only reports an object once it has stayed unreferenced for\n+# min_unref_scans consecutive scans. The default of 1 reports on the first\n+# scan (historical behaviour); higher values filter transient false\n+# positives where a live object's only reference is briefly invisible to a\n+# single scan (e.g. an RCU tree update in flight while the scan runs). The\n+# test loads samples/kmemleak's helper module to create orphan allocations\n+# and, counting only those orphans (matched by their [kmemleak_test]\n+# backtrace so unrelated leaks already present on the system are ignored),\n+# checks that:\n+#   - a freshly allocated object is greyed on its first scan (its checksum\n+#     settles then), so nothing can be reported before that priming scan;\n+#     each case below primes once first,\n+#   - with the default threshold (min_unref_scans=1) one scan after priming\n+#     reports the orphans,\n+#   - raising the threshold to 2 needs two scans after priming: one is not\n+#     enough, the second reports,\n+#   - the parameter reads back what was written.\n+#\n+# The \"one post-prime scan is not enough at min_unref_scans=2\" check is the\n+# core regression test: raising min_unref_scans must push the report\n+# strictly later. Like ksft_kmemleak_dedup.sh, if the module yields no\n+# detectable orphan at all in the running environment the test skips rather\n+# than failing.\n+#\n+# Author: Breno Leitao \u003cleitao@debian.org\u003e\n+\n+# KTAP output helpers (ktap_skip_all, ktap_exit_fail_msg, ktap_test_pass, ...).\n+DIR=\"$(dirname \"$(readlink -f \"$0\")\")\"\n+# shellcheck source=../kselftest/ktap_helpers.sh\n+source \"${DIR}\"/../kselftest/ktap_helpers.sh\n+\n+KMEMLEAK=/sys/kernel/debug/kmemleak\n+PARAM=/sys/module/kmemleak/parameters/min_unref_scans\n+MODULE=kmemleak-test\n+AGE=6\t\t# seconds; must exceed kmemleak's 5s minimum object age\n+\n+ktap_print_header\n+\n+[ \"$(id -u)\" -eq 0 ] || { ktap_skip_all \"must run as root\"; exit \"$KSFT_SKIP\"; }\n+[ -r \"$KMEMLEAK\" ] ||\n+\t{ ktap_skip_all \"no kmemleak debugfs (CONFIG_DEBUG_KMEMLEAK)\"; exit \"$KSFT_SKIP\"; }\n+[ -w \"$PARAM\" ] ||\n+\t{ ktap_skip_all \"min_unref_scans module parameter not present\"; exit \"$KSFT_SKIP\"; }\n+modinfo \"$MODULE\" \u003e/dev/null 2\u003e\u00261 ||\n+\t{ ktap_skip_all \"$MODULE not built (CONFIG_SAMPLE_KMEMLEAK)\"; exit \"$KSFT_SKIP\"; }\n+\n+# kmemleak can be present but disabled at runtime (kmemleak=off boot arg,\n+# or it self-disabled after an internal error); a \"scan\" then returns\n+# EPERM. Probe once and skip if so.\n+echo scan \u003e \"$KMEMLEAK\" 2\u003e/dev/null ||\n+\t{ ktap_skip_all \"kmemleak is disabled (check dmesg or kmemleak= boot arg)\"; exit \"$KSFT_SKIP\"; }\n+\n+prev=$(cat \"$PARAM\")\n+# shellcheck disable=SC2317  # invoked indirectly via trap\n+cleanup() {\n+\techo \"$prev\" \u003e \"$PARAM\" 2\u003e/dev/null\t\t# restore the parameter\n+\techo scan=on \u003e \"$KMEMLEAK\" 2\u003e/dev/null\t\t# re-enable auto scan\n+\trmmod \"$MODULE\" 2\u003e/dev/null\n+\techo clear \u003e \"$KMEMLEAK\" 2\u003e/dev/null\n+}\n+trap cleanup EXIT\n+\n+# Stop the automatic scan thread: only our manual scans should advance an\n+# object's consecutive-unreferenced run. An auto scan landing between two\n+# manual scans would change the result and make the test flaky.\n+echo scan=off \u003e \"$KMEMLEAK\" 2\u003e/dev/null\n+\n+# Create a fresh, aged set of orphan objects from the helper module's init\n+# path (its kmalloc/vmalloc/percpu allocations are dropped right away).\n+# Pre-existing reported leaks are greyed first (\"clear\") so only our\n+# orphans are counted. The module is left loaded on purpose: once it is\n+# unloaded its symbols are gone, so the orphan backtraces no longer resolve\n+# to [kmemleak_test] and could not be matched below.\n+gen_orphans() {\n+\trmmod \"$MODULE\" 2\u003e/dev/null\n+\techo clear \u003e \"$KMEMLEAK\"\n+\tmodprobe \"$MODULE\" ||\n+\t\t{ ktap_skip_all \"failed to load $MODULE\"; exit \"$KSFT_SKIP\"; }\n+\tsleep \"$AGE\"\n+}\n+\n+scan() { echo scan \u003e \"$KMEMLEAK\"; }\n+\n+# Number of helper-module orphans currently reported by kmemleak. Matching\n+# the module's own backtrace ([kmemleak_test]) keeps the count immune to\n+# unrelated leaks on the running system. kmemleak only lists an object here\n+# once it has been reported, so this reflects the confirmation gating.\n+count_orphans() {\n+\tc=$(grep -c '\\[kmemleak_test\\]' \"$KMEMLEAK\" 2\u003e/dev/null)\n+\techo \"${c:-0}\"\n+}\n+\n+# 0) the parameter reads back what was written.\n+echo 3 \u003e \"$PARAM\"\n+[ \"$(cat \"$PARAM\")\" = \"3\" ] || ktap_exit_fail_msg \"min_unref_scans did not read back as 3\"\n+\n+# Priming scan: kmemleak greys a freshly allocated object on its first scan\n+# (its checksum settles then), so nothing can be reported until a second\n+# scan. Every case below runs this priming scan before counting.\n+prime() { scan; }\n+\n+# 1) min_unref_scans=1 (default): one scan after priming reports the\n+#    orphans. This also establishes that the helper produces detectable\n+#    orphans here.\n+echo 1 \u003e \"$PARAM\"\n+gen_orphans\n+prime\n+scan\n+first=$(count_orphans)\n+[ \"$first\" -gt 0 ] ||\n+\t{ ktap_skip_all \"$MODULE produced no detectable orphans (cannot test min_unref_scans)\"; exit \"$KSFT_SKIP\"; }\n+\n+# 2) min_unref_scans=2: after priming, one scan is not enough (still\n+#    gated), the second reports. The gated-scan-zero check is the core\n+#    regression.\n+echo 2 \u003e \"$PARAM\"\n+gen_orphans\n+prime\n+scan; s1=$(count_orphans)\n+scan; s2=$(count_orphans)\n+[ \"$s1\" -eq 0 ] || ktap_exit_fail_msg \"min_unref_scans=2: $s1 orphan(s) after 1 post-prime scan (must be 0)\"\n+[ \"$s2\" -gt 0 ] || ktap_exit_fail_msg \"min_unref_scans=2: no report after 2 post-prime scans (false negative)\"\n+\n+ktap_set_plan 1\n+ktap_test_pass \"min_unref_scans=1 reported $first orphan(s) one scan after priming; =2 held them one scan longer ($s1 after one scan, $s2 after two); param read-back ok\"\n+ktap_finished\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "DEBUG_KMEMLEAK"
  ],
  "FocusSymbols": [
    "__kmemleak_scan",
    "confirm_leak",
    "kmemleak_scan"
  ],
  "Reasoning": "The patch modifies the memory leak detection logic in kmemleak, introducing a new parameter `min_unref_scans` and changing how objects are confirmed as leaks. This is functional kernel code that can be reached via the kmemleak scan thread or debugfs interface.",
  "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).

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.
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.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. 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 bd0f857b513eb98bdc9c241aac503828600ac52a
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Jul 13 14:45:18 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst
index 7d784e03f3f9d5..a8a83bc69ceb88 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -198,6 +198,14 @@ systems, because of pointers temporarily stored in CPU registers or
 stacks. Kmemleak defines MSECS_MIN_AGE (defaulting to 1000) representing
 the minimum age of an object to be reported as a memory leak.
 
+The ``min_unref_scans`` module parameter (default 1) requires an object to
+be seen unreferenced in that many consecutive scans before it is reported.
+Keeping it at 1 preserves the historical behaviour; higher values filter
+the transient false positives described above, at the cost of delaying
+genuine reports by up to that many scans. It can be set at boot with
+``kmemleak.min_unref_scans=<n>`` or at run-time via
+``/sys/module/kmemleak/parameters/min_unref_scans``.
+
 Limitations and Drawbacks
 -------------------------
 
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index e96e9efd19b0d9..85f18b17e79c4e 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -151,6 +151,8 @@ struct kmemleak_object {
 	int min_count;
 	/* the total number of pointers found pointing to this object */
 	int count;
+	/* consecutive scans the object has been seen unreferenced */
+	unsigned int unref_scans;
 	/* checksum for detecting modified objects */
 	u32 checksum;
 	depot_stack_handle_t trace_handle;
@@ -175,6 +177,8 @@ struct kmemleak_object {
 #define OBJECT_PHYS		(1 << 4)
 /* flag set for per-CPU pointers */
 #define OBJECT_PERCPU		(1 << 5)
+/* flag set on an object left unreferenced by the full scan, pending confirmation */
+#define OBJECT_SUSPECT		(1 << 6)
 
 /* set when __remove_object() called */
 #define DELSTATE_REMOVED	(1 << 0)
@@ -232,9 +236,14 @@ static unsigned long max_percpu_addr;
 static struct task_struct *scan_thread;
 /* used to avoid reporting of recently allocated objects */
 static unsigned long jiffies_min_age;
+/* consecutive scans an object must stay unreferenced before reporting */
+static unsigned int min_unref_scans = 1;
+module_param(min_unref_scans, uint, 0644);
 static unsigned long jiffies_last_scan;
 /* delay between automatic memory scannings */
 static unsigned long jiffies_scan_wait;
+/* number of objects flagged OBJECT_SUSPECT during the current scan */
+static int nr_suspects;
 /* enables or disables the task stacks scanning */
 static int kmemleak_stack_scan = 1;
 /* protects the memory scanning, parameters and debug/kmemleak file access */
@@ -688,6 +697,7 @@ static struct kmemleak_object *__alloc_object(gfp_t gfp)
 	object->excess_ref = 0;
 	object->count = 0;			/* white color initially */
 	object->checksum = ~0;
+	object->unref_scans = 0;
 	object->del_state = 0;
 
 	/* task information */
@@ -1440,6 +1450,11 @@ static void update_refs(struct kmemleak_object *object)
 	 */
 	object->count++;
 	if (color_gray(object)) {
+		/* referenced after all, no longer a suspect */
+		if (object->flags & OBJECT_SUSPECT) {
+			object->flags &= ~OBJECT_SUSPECT;
+			nr_suspects--;
+		}
 		/* put_object() called when removing from gray_list */
 		WARN_ON(!get_object(object));
 		list_add_tail(&object->gray_list, &gray_list);
@@ -1844,16 +1859,16 @@ static void dedup_flush(struct xarray *dedup)
  * kernel's standard allocators. This function must be called with the
  * scan_mutex held.
  */
-static void kmemleak_scan(void)
+static int __kmemleak_scan(bool full)
 {
 	struct kmemleak_object *object;
 	struct zone *zone;
 	int __maybe_unused i;
-	struct xarray dedup;
-	int new_leaks = 0;
 	int stop = 0;
 
 	jiffies_last_scan = jiffies;
+	if (full)
+		nr_suspects = 0;
 
 	/* prepare the kmemleak_object's */
 	rcu_read_lock();
@@ -1881,8 +1896,13 @@ static void kmemleak_scan(void)
 				__paint_it(object, KMEMLEAK_BLACK);
 		}
 
+		/* referenced last scan: restart the unreferenced run */
+		if (!color_white(object))
+			object->unref_scans = 0;
 		/* reset the reference count (whiten the object) */
 		object->count = 0;
+		if (full)
+			object->flags &= ~OBJECT_SUSPECT;
 		if (color_gray(object) && get_object(object))
 			list_add_tail(&object->gray_list, &gray_list);
 
@@ -1950,6 +1970,10 @@ static void kmemleak_scan(void)
 scan_gray:
 	scan_gray_list();
 
+	/* a confirmation scan does not look for modified objects */
+	if (!full)
+		return nr_suspects;
+
 	/*
 	 * Check for new or unreferenced objects modified since the previous
 	 * scan and color them gray until the next scan.
@@ -1972,6 +1996,11 @@ static void kmemleak_scan(void)
 			/* color it gray temporarily */
 			object->count = object->min_count;
 			list_add_tail(&object->gray_list, &gray_list);
+		} else if (unreferenced_object(object) &&
+			   !(object->flags & OBJECT_REPORTED)) {
+			/* flag the objects left unreferenced by this scan */
+			object->flags |= OBJECT_SUSPECT;
+			nr_suspects++;
 		}
 		raw_spin_unlock_irq(&object->lock);
 	}
@@ -1982,12 +2011,62 @@ static void kmemleak_scan(void)
 	 */
 	scan_gray_list();
 
+	return nr_suspects;
+}
+
+/*
+ * Promote a suspected object to a reported leak once it has stayed
+ * unreferenced for min_unref_scans consecutive scans. Called with
+ * object->lock held; returns true when the object is newly reported.
+ */
+static bool confirm_leak(struct kmemleak_object *object)
+{
+	if (!unreferenced_object(object) ||
+	    !(object->flags & OBJECT_SUSPECT) ||
+	    (object->flags & OBJECT_REPORTED))
+		return false;
+
+	object->unref_scans += 1;
+	if (object->unref_scans < min_unref_scans)
+		return false;
+
+	object->flags |= OBJECT_REPORTED;
+	return true;
+}
+
+/*
+ * Scan the memory and report the unreferenced objects as leaks. Must be
+ * called with the scan_mutex held.
+ */
+static void kmemleak_scan(void)
+{
+	struct kmemleak_object *object;
+	struct xarray dedup;
+	int new_leaks = 0;
+
+	/*
+	 * Full scan. Objects left unreferenced are flagged OBJECT_SUSPECT and
+	 * counted in the return value; nothing to confirm or report otherwise.
+	 */
+	if (!__kmemleak_scan(true))
+		return;
+
 	/*
 	 * If scanning was stopped do not report any new unreferenced objects.
 	 */
 	if (scan_should_stop())
 		return;
 
+	/*
+	 * A live object whose only reference is moved by, for example, a
+	 * concurrent RCU update can be missed for one scan and reported as a
+	 * transient false positive. Scan again and only report the objects
+	 * left unreferenced (still flagged OBJECT_SUSPECT) by both scans.
+	 */
+	__kmemleak_scan(false);
+	if (scan_should_stop())
+		return;
+
 	/*
 	 * Scanning result reporting. When verbose printing is enabled, dedupe
 	 * by stackdepot trace_handle so each unique backtrace is logged once
@@ -2014,9 +2093,8 @@ static void kmemleak_scan(void)
 		raw_spin_lock_irq(&object->lock);
 		trace_handle = 0;
 		dedup_print = false;
-		if (unreferenced_object(object) &&
-		    !(object->flags & OBJECT_REPORTED)) {
-			object->flags |= OBJECT_REPORTED;
+
+		if (confirm_leak(object)) {
 			if (kmemleak_verbose) {
 				trace_handle = object->trace_handle;
 				dedup_print = true;
diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
index ed321ae709dacf..786b1d73d93b0a 100644
--- a/tools/testing/selftests/mm/Makefile
+++ b/tools/testing/selftests/mm/Makefile
@@ -150,6 +150,7 @@ TEST_PROGS += ksft_gup_test.sh
 TEST_PROGS += ksft_hmm.sh
 TEST_PROGS += ksft_hugetlb.sh
 TEST_PROGS += ksft_hugevm.sh
+TEST_PROGS += ksft_kmemleak_confirm.sh
 TEST_PROGS += ksft_kmemleak_dedup.sh
 TEST_PROGS += ksft_ksm.sh
 TEST_PROGS += ksft_ksm_numa.sh
diff --git a/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh b/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh
new file mode 100755
index 00000000000000..3a8576e835c8d1
--- /dev/null
+++ b/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh
@@ -0,0 +1,132 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Functional test for kmemleak's N-consecutive-scan leak confirmation
+# (the min_unref_scans module parameter).
+#
+# kmemleak only reports an object once it has stayed unreferenced for
+# min_unref_scans consecutive scans. The default of 1 reports on the first
+# scan (historical behaviour); higher values filter transient false
+# positives where a live object's only reference is briefly invisible to a
+# single scan (e.g. an RCU tree update in flight while the scan runs). The
+# test loads samples/kmemleak's helper module to create orphan allocations
+# and, counting only those orphans (matched by their [kmemleak_test]
+# backtrace so unrelated leaks already present on the system are ignored),
+# checks that:
+#   - a freshly allocated object is greyed on its first scan (its checksum
+#     settles then), so nothing can be reported before that priming scan;
+#     each case below primes once first,
+#   - with the default threshold (min_unref_scans=1) one scan after priming
+#     reports the orphans,
+#   - raising the threshold to 2 needs two scans after priming: one is not
+#     enough, the second reports,
+#   - the parameter reads back what was written.
+#
+# The "one post-prime scan is not enough at min_unref_scans=2" check is the
+# core regression test: raising min_unref_scans must push the report
+# strictly later. Like ksft_kmemleak_dedup.sh, if the module yields no
+# detectable orphan at all in the running environment the test skips rather
+# than failing.
+#
+# Author: Breno Leitao <leitao@debian.org>
+
+# KTAP output helpers (ktap_skip_all, ktap_exit_fail_msg, ktap_test_pass, ...).
+DIR="$(dirname "$(readlink -f "$0")")"
+# shellcheck source=../kselftest/ktap_helpers.sh
+source "${DIR}"/../kselftest/ktap_helpers.sh
+
+KMEMLEAK=/sys/kernel/debug/kmemleak
+PARAM=/sys/module/kmemleak/parameters/min_unref_scans
+MODULE=kmemleak-test
+AGE=6		# seconds; must exceed kmemleak's 5s minimum object age
+
+ktap_print_header
+
+[ "$(id -u)" -eq 0 ] || { ktap_skip_all "must run as root"; exit "$KSFT_SKIP"; }
+[ -r "$KMEMLEAK" ] ||
+	{ ktap_skip_all "no kmemleak debugfs (CONFIG_DEBUG_KMEMLEAK)"; exit "$KSFT_SKIP"; }
+[ -w "$PARAM" ] ||
+	{ ktap_skip_all "min_unref_scans module parameter not present"; exit "$KSFT_SKIP"; }
+modinfo "$MODULE" >/dev/null 2>&1 ||
+	{ ktap_skip_all "$MODULE not built (CONFIG_SAMPLE_KMEMLEAK)"; exit "$KSFT_SKIP"; }
+
+# kmemleak can be present but disabled at runtime (kmemleak=off boot arg,
+# or it self-disabled after an internal error); a "scan" then returns
+# EPERM. Probe once and skip if so.
+echo scan > "$KMEMLEAK" 2>/dev/null ||
+	{ ktap_skip_all "kmemleak is disabled (check dmesg or kmemleak= boot arg)"; exit "$KSFT_SKIP"; }
+
+prev=$(cat "$PARAM")
+# shellcheck disable=SC2317  # invoked indirectly via trap
+cleanup() {
+	echo "$prev" > "$PARAM" 2>/dev/null		# restore the parameter
+	echo scan=on > "$KMEMLEAK" 2>/dev/null		# re-enable auto scan
+	rmmod "$MODULE" 2>/dev/null
+	echo clear > "$KMEMLEAK" 2>/dev/null
+}
+trap cleanup EXIT
+
+# Stop the automatic scan thread: only our manual scans should advance an
+# object's consecutive-unreferenced run. An auto scan landing between two
+# manual scans would change the result and make the test flaky.
+echo scan=off > "$KMEMLEAK" 2>/dev/null
+
+# Create a fresh, aged set of orphan objects from the helper module's init
+# path (its kmalloc/vmalloc/percpu allocations are dropped right away).
+# Pre-existing reported leaks are greyed first ("clear") so only our
+# orphans are counted. The module is left loaded on purpose: once it is
+# unloaded its symbols are gone, so the orphan backtraces no longer resolve
+# to [kmemleak_test] and could not be matched below.
+gen_orphans() {
+	rmmod "$MODULE" 2>/dev/null
+	echo clear > "$KMEMLEAK"
+	modprobe "$MODULE" ||
+		{ ktap_skip_all "failed to load $MODULE"; exit "$KSFT_SKIP"; }
+	sleep "$AGE"
+}
+
+scan() { echo scan > "$KMEMLEAK"; }
+
+# Number of helper-module orphans currently reported by kmemleak. Matching
+# the module's own backtrace ([kmemleak_test]) keeps the count immune to
+# unrelated leaks on the running system. kmemleak only lists an object here
+# once it has been reported, so this reflects the confirmation gating.
+count_orphans() {
+	c=$(grep -c '\[kmemleak_test\]' "$KMEMLEAK" 2>/dev/null)
+	echo "${c:-0}"
+}
+
+# 0) the parameter reads back what was written.
+echo 3 > "$PARAM"
+[ "$(cat "$PARAM")" = "3" ] || ktap_exit_fail_msg "min_unref_scans did not read back as 3"
+
+# Priming scan: kmemleak greys a freshly allocated object on its first scan
+# (its checksum settles then), so nothing can be reported until a second
+# scan. Every case below runs this priming scan before counting.
+prime() { scan; }
+
+# 1) min_unref_scans=1 (default): one scan after priming reports the
+#    orphans. This also establishes that the helper produces detectable
+#    orphans here.
+echo 1 > "$PARAM"
+gen_orphans
+prime
+scan
+first=$(count_orphans)
+[ "$first" -gt 0 ] ||
+	{ ktap_skip_all "$MODULE produced no detectable orphans (cannot test min_unref_scans)"; exit "$KSFT_SKIP"; }
+
+# 2) min_unref_scans=2: after priming, one scan is not enough (still
+#    gated), the second reports. The gated-scan-zero check is the core
+#    regression.
+echo 2 > "$PARAM"
+gen_orphans
+prime
+scan; s1=$(count_orphans)
+scan; s2=$(count_orphans)
+[ "$s1" -eq 0 ] || ktap_exit_fail_msg "min_unref_scans=2: $s1 orphan(s) after 1 post-prime scan (must be 0)"
+[ "$s2" -gt 0 ] || ktap_exit_fail_msg "min_unref_scans=2: no report after 2 post-prime scans (false negative)"
+
+ktap_set_plan 1
+ktap_test_pass "min_unref_scans=1 reported $first orphan(s) one scan after priming; =2 held them one scan longer ($s1 after one scan, $s2 after two); param read-back ok"
+ktap_finished

gemini-3.1-pro-preview

null

null

							input: 6350
							output: 21
							thoughts: 729
						

**Fuzzing Kmemleak: A Deliberation**

Okay, so I've got this patch that tweaks `mm/kmemleak.c` and adds a new test. My initial thought? Is this worth fuzzing? Kmemleak is a debugging tool, a background scanner for memory leaks, so it's not like it's directly handling user input or networking traffic. Usually, syzkaller focuses on the core kernel logic. But, hang on... it *is* a kernel feature that can be enabled and configured.

I need to step back. What are the criteria? This prompt lists exceptions for fuzzing, and I need to check against those. Does the patch change *reachable* core kernel logic? Yes, it modifies `mm/kmemleak.c`. Is kmemleak considered core kernel? It's a memory leak *detector*. Can it run in virtualized environments? Yes. Does it introduce functional changes? Absolutely – it alters the scanning logic with this new `min_unref_scans` parameter and the logic around it, including `kmemleak_scan`, `__kmemleak_scan`, and `confirm_leak`.

So, the question shifts: is it worth *fuzzing* kmemleak's internal logic *directly*? We can interact with `/sys/kernel/debug/kmemleak` and adjust the configuration through `/sys/module/kmemleak/parameters/min_unref_scans`... that's a vector for fuzzing, which suggests that this is worth exploring, and that the syzkaller setup could be modified to test kmemleak itself.

I need to confirm the approach for this patch. I could target the functions altered like `__kmemleak_scan`, `confirm_leak`, and `kmemleak_scan`. And consider whether this tool is actually targeted by syzkaller.

Ah, kmemleak is a background thread or triggered via debugfs... and syzkaller does target debugfs sometimes! Interesting... even if the primary focus isn't kmemleak itself, it's *still* kernel code. Race conditions or even use-after-free bugs within kmemleak are conceivable.

I think this is worth pursuing, even if it's not the primary target. We're changing core code, the patch introduces new functionality, and it's reachable in a standard environment, so there's potential to discover new bugs.

I need to check how it's enabled: `CONFIG_DEBUG_KMEMLEAK`. Let's grep for that and see how widely it's used.

{
  "Expression": "config DEBUG_KMEMLEAK"
}

{
  "Output": "mm/Kconfig.debug=237=config HAVE_DEBUG_KMEMLEAK\n--\nmm/Kconfig.debug-239-\nmm/Kconfig.debug:240:config DEBUG_KMEMLEAK\nmm/Kconfig.debug-241-\tbool \"Kernel memory leak detector\"\n--\nmm/Kconfig.debug-264-\nmm/Kconfig.debug:265:config DEBUG_KMEMLEAK_MEM_POOL_SIZE\nmm/Kconfig.debug-266-\tint \"Kmemleak memory pool size\"\n--\nmm/Kconfig.debug-277-\nmm/Kconfig.debug:278:config DEBUG_KMEMLEAK_DEFAULT_OFF\nmm/Kconfig.debug-279-\tbool \"Default kmemleak to off\"\n--\nmm/Kconfig.debug-284-\nmm/Kconfig.debug:285:config DEBUG_KMEMLEAK_AUTO_SCAN\nmm/Kconfig.debug-286-\tbool \"Enable kmemleak auto scan thread on boot up\"\n--\nmm/Kconfig.debug-299-\nmm/Kconfig.debug:300:config DEBUG_KMEMLEAK_VERBOSE\nmm/Kconfig.debug-301-\tbool \"Default kmemleak to verbose mode\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 7980
							output: 33
							thoughts: 369
						

**Analyzing the Kernel Memory Leak Detection Patch**

Okay, so this patch introduces a new parameter, `min_unref_scans`, and it adds the `confirm_leak` function. I see modifications to both `__kmemleak_scan` and `kmemleak_scan`. Let me quickly check if there are any other configuration variables or dependencies affected here... no, just `DEBUG_KMEMLEAK`.

Hmm, now the key question: is this even worth fuzzing? Let me review the criteria... Ah, the guidelines say "WorthFuzzing=false" if it's just docs, Kconfig, comments, decorative changes, or constants that don't alter execution. Also, unreachable code paths in virtualized environments are not worth fuzzing.

But this is touching `mm/kmemleak.c`, which is definitely core kernel logic, if enabled, which it likely is in a lot of builds. And the changes seem functional; it's altering how leak confirmation works. So, yep, `WorthFuzzing=true`.

Okay, let's nail down the focus symbols for fuzzing: `confirm_leak`, `__kmemleak_scan`, and `kmemleak_scan`.

Let's quickly verify these functions: are they static? Yep, `__kmemleak_scan`, `confirm_leak`, and `kmemleak_scan` are all static within `mm/kmemleak.c`. Good to know for symbol visibility during fuzzing.

Now, let's just do a quick scan of `mm/kmemleak.c` to see if there are other, related functions that are also modified. Make sure I haven't missed anything.

{
  "Expression": "__kmemleak_scan",
  "PathPrefix": "mm/kmemleak.c"
}

{
  "Output": "mm/kmemleak.c=1837=static void dedup_flush(struct xarray *dedup)\n--\nmm/kmemleak.c-1861- */\nmm/kmemleak.c:1862:static int __kmemleak_scan(bool full)\nmm/kmemleak.c-1863-{\n--\nmm/kmemleak.c=2041=static void kmemleak_scan(void)\n--\nmm/kmemleak.c-2050-\t */\nmm/kmemleak.c:2051:\tif (!__kmemleak_scan(true))\nmm/kmemleak.c-2052-\t\treturn;\n--\nmm/kmemleak.c-2065-\t */\nmm/kmemleak.c:2066:\t__kmemleak_scan(false);\nmm/kmemleak.c-2067-\tif (scan_should_stop())\n"
}

gemini-3.1-pro-preview

null

null

							input: 8993
							output: 30
							thoughts: 14
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing the Impact of the `update_refs` Modification**

Okay, so I see a modification to the `update_refs` function. My immediate thought is, given its name, this function is *probably* related to updating references within this system – likely pointers, indices, or identifiers of some kind. Now that it is modified I need to examine this function's scope. Given that this code change is touching this piece of code, I need to understand the relationship between this code and other modules. Let's delve in and see what exactly has changed within `update_refs` itself, because any change there has potential for downstream effects. I need to understand what this will impact. A change here could cascade through various data structures or control flows, making it important to look at this function first.

{
  "Expression": "update_refs",
  "PathPrefix": "mm/kmemleak.c"
}

{
  "Output": "mm/kmemleak.c=1407=static bool update_checksum(struct kmemleak_object *object)\n--\nmm/kmemleak.c-1437- */\nmm/kmemleak.c:1438:static void update_refs(struct kmemleak_object *object)\nmm/kmemleak.c-1439-{\n--\nmm/kmemleak.c-1463-\nmm/kmemleak.c:1464:static void pointer_update_refs(struct kmemleak_object *scanned,\nmm/kmemleak.c-1465-\t\t\t unsigned long pointer, unsigned int objflags)\n--\nmm/kmemleak.c-1501-\t\texcess_ref = object-\u003eexcess_ref;\nmm/kmemleak.c:1502:\t\t/* no need for update_refs() if object already gray */\nmm/kmemleak.c-1503-\t} else {\nmm/kmemleak.c-1504-\t\texcess_ref = 0;\nmm/kmemleak.c:1505:\t\tupdate_refs(object);\nmm/kmemleak.c-1506-\t}\n--\nmm/kmemleak.c-1516-\t\traw_spin_lock_nested(\u0026object-\u003elock, SINGLE_DEPTH_NESTING);\nmm/kmemleak.c:1517:\t\tupdate_refs(object);\nmm/kmemleak.c-1518-\t\traw_spin_unlock(\u0026object-\u003elock);\n--\nmm/kmemleak.c=1545=static int scan_block(void *_start, void *_end,\n--\nmm/kmemleak.c-1566-\nmm/kmemleak.c:1567:\t\tpointer_update_refs(scanned, pointer, 0);\nmm/kmemleak.c:1568:\t\tpointer_update_refs(scanned, pointer, OBJECT_PERCPU);\nmm/kmemleak.c-1569-\t}\n"
}

gemini-3.1-pro-preview

null

null

							input: 9730
							output: 117
							thoughts: 683
						

**My Analysis of Kmemleak Configuration for Fuzzing**

Okay, let's break this down. My goal is to identify the *specific* kernel configurations needed to effectively fuzz the modified kmemleak code. I'm focusing on the functions that have been touched by this patch: `__alloc_object`, `update_refs`, `__kmemleak_scan`, `confirm_leak`, and `kmemleak_scan`.

First, I need to consider performance. `__alloc_object` and `update_refs` are hot-path functions, so ideally, I would avoid them as fuzzing targets since fuzzing in hot paths can lead to performance issues.  `__kmemleak_scan`, `confirm_leak`, and `kmemleak_scan` are more interesting because they're part of the scan process, triggered periodically or manually.  These are prime candidates for fuzzing, and I need to make sure the right configurations enable them.

Now, the prompt specifically tells me not to list generic configs.  But is `DEBUG_KMEMLEAK` too generic?  No, it's specific to the kmemleak *debug* feature itself.  While it *might* be enabled in some instances, I think it's crucial to explicitly enable it for my fuzzing. This seems like the *main* config. I am going to list `DEBUG_KMEMLEAK`.

Let me quickly re-examine those scan functions.  `kmemleak_scan` is the main scan function. Is it hot-path? No, it's called periodically by `kmemleak_scan_thread` or manually through debugfs, so that's good.

Alright, let's step back and consider the *purpose* of these changes. This patch is modifying the memory leak detection logic, specifically the unreferenced scan threshold and how objects are confirmed as leaks.  This directly affects the functionality of kmemleak and can be triggered via the kmemleak scan thread or debugfs.

Focusing on the function symbols: `__kmemleak_scan`, `confirm_leak`, and `kmemleak_scan`, I'll double-check they're there.  `confirm_leak` is a new static function added in this patch. And yes, `__kmemleak_scan` is present, it's been modified in the patch (possibly renamed or changed). And `kmemleak_scan` also exists.

Are there any other relevant configs? The test uses `CONFIG_SAMPLE_KMEMLEAK`, but that's for a selftest. I don't need to enable that specific module to fuzz the core kmemleak logic itself. That appears to be it.

Therefore, for this fuzzing effort, I'm confident that the critical configuration is just `DEBUG_KMEMLEAK`.

{
  "EnableConfigs": [
    "DEBUG_KMEMLEAK"
  ],
  "FocusSymbols": [
    "__kmemleak_scan",
    "confirm_leak",
    "kmemleak_scan"
  ],
  "Reasoning": "The patch modifies the memory leak detection logic in kmemleak, introducing a new parameter `min_unref_scans` and changing how objects are confirmed as leaks. This is functional kernel code that can be reached via the kmemleak scan thread or debugfs interface.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "DEBUG_KMEMLEAK"
  ],
  "FocusSymbols": [
    "__kmemleak_scan",
    "confirm_leak",
    "kmemleak_scan"
  ],
  "Reasoning": "The patch modifies the memory leak detection logic in kmemleak, introducing a new parameter `min_unref_scans` and changing how objects are confirmed as leaks. This is functional kernel code that can be reached via the kmemleak scan thread or debugfs interface.",
  "WorthFuzzing": true
}