| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/05 17:38 | flow | patch-triage |
0mArgs:null Results: {
"EnableConfigs": [
"BPF_SYSCALL"
],
"FocusSymbols": [
"check_cond_jmp_op",
"is_branch_taken",
"reg_not_null",
"bpf_check"
],
"KMSANReasoning": "The patch modifies the BPF verifier's logic in `kernel/bpf/verifier.c` to fix soundness issues regarding register tracking, specifically:\n1. Handling offset wrapping to zero in `reg_not_null()`.\n2. Handling 32-bit pointer-vs-scalar comparisons in `is_branch_taken()`.\n3. Ensuring linked registers are collected before saving registers in `check_cond_jmp_op()`.\n4. Marking precision on `src_reg` when checking nullness in `check_cond_jmp_op()`.\n\nThese changes do not introduce or modify uninitialized memory handling, structure padding, uninitialized buffers, or copies to user space. The structures manipulated (such as `struct linked_regs`) are initialized properly (e.g., zero-initialized on declaration), and the changes solely affect verifier internal control-flow and register state logic. Any potential misbehavior prevented by these fixes relates to BPF verification soundness (e.g., out-of-bounds accesses, NULL dereferences), which is covered by KASAN and standard sanitizers. Therefore, dedicated KMSAN fuzzing is not required.",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies BPF verifier logic in kernel/bpf/verifier.c for pointer nullness inference, 32-bit jump branch prediction, linked registers collection timing, and precision tracking on register comparisons. These changes affect reachable verification paths when loading BPF programs via the bpf() system call and warrant fuzzing.",
"WorthFuzzing": true
} |
| 1/1 | 2026/09/05 17:38 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit b4c5df61cfb59c520846e7be0f1827f2128897e6\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Sat Sep 5 17:38:01 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c\nindex e640356837951..709b4793e8eb7 100644\n--- a/kernel/bpf/verifier.c\n+++ b/kernel/bpf/verifier.c\n@@ -352,6 +352,13 @@ static bool reg_not_null(struct bpf_verifier_env *env, const struct bpf_reg_stat\n \tif (type_may_be_null(type))\n \t\treturn false;\n \n+\t/*\n+\t * The types below guarantee a non-NULL base, an unbounded offset can\n+\t * still wrap base + offset to zero.\n+\t */\n+\tif (reg_smin(reg) \u003c= -BPF_MAX_VAR_OFF || reg_smax(reg) \u003e= BPF_MAX_VAR_OFF)\n+\t\treturn false;\n+\n \ttype = base_type(type);\n \treturn type == PTR_TO_SOCKET ||\n \t\ttype == PTR_TO_TCP_SOCK ||\n@@ -16302,6 +16309,13 @@ static int is_branch_taken(struct bpf_verifier_env *env, struct bpf_reg_state *r\n \tif (__is_pointer_value(false, reg1) || __is_pointer_value(false, reg2)) {\n \t\tu64 val;\n \n+\t\t/*\n+\t\t * The low 32 bits of a valid pointer may well be zero, hence\n+\t\t * nothing below applies to a 32-bit comparison.\n+\t\t */\n+\t\tif (is_jmp32)\n+\t\t\treturn -1;\n+\n \t\t/* arrange that reg2 is a scalar, and reg1 is a pointer */\n \t\tif (!is_reg_const(reg2, is_jmp32)) {\n \t\t\topcode = flip_opcode(opcode);\n@@ -16863,6 +16877,16 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,\n \t\t\treturn err;\n \t}\n \n+\t/*\n+\t * Collect the linked registers before env-\u003e{true,false}_reg{1,2} setup,\n+\t * otherwise ids dropped by collect_linked_regs() would be resurrected\n+\t * when env-\u003e{true,false}_reg{1,2} are copied back.\n+\t */\n+\tif (BPF_SRC(insn-\u003ecode) == BPF_X \u0026\u0026 src_reg-\u003etype == SCALAR_VALUE \u0026\u0026 src_reg-\u003eid)\n+\t\tcollect_linked_regs(env, this_branch, src_reg-\u003eid, \u0026linked_regs);\n+\tif (dst_reg-\u003etype == SCALAR_VALUE \u0026\u0026 dst_reg-\u003eid)\n+\t\tcollect_linked_regs(env, this_branch, dst_reg-\u003eid, \u0026linked_regs);\n+\n \tis_jmp32 = BPF_CLASS(insn-\u003ecode) == BPF_JMP32;\n \tenv-\u003efalse_reg1 = *dst_reg;\n \tenv-\u003efalse_reg2 = *src_reg;\n@@ -16917,10 +16941,6 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,\n \t * 'this_branch' and 'other_branch' share this history\n \t * if parent state is created.\n \t */\n-\tif (BPF_SRC(insn-\u003ecode) == BPF_X \u0026\u0026 src_reg-\u003etype == SCALAR_VALUE \u0026\u0026 src_reg-\u003eid)\n-\t\tcollect_linked_regs(env, this_branch, src_reg-\u003eid, \u0026linked_regs);\n-\tif (dst_reg-\u003etype == SCALAR_VALUE \u0026\u0026 dst_reg-\u003eid)\n-\t\tcollect_linked_regs(env, this_branch, dst_reg-\u003eid, \u0026linked_regs);\n \tif (linked_regs.cnt \u003e 1) {\n \t\terr = bpf_push_jmp_history(env, this_branch, 0, 0, 0, linked_regs_pack(\u0026linked_regs));\n \t\tif (err)\n@@ -17004,6 +17024,15 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,\n \t type_may_be_null(dst_reg-\u003etype) \u0026\u0026\n \t ((BPF_SRC(insn-\u003ecode) == BPF_K \u0026\u0026 insn-\u003eimm == 0) ||\n \t (BPF_SRC(insn-\u003ecode) == BPF_X \u0026\u0026 bpf_register_is_null(src_reg)))) {\n+\t\t/*\n+\t\t * For BPF_X the zero is a property of this execution path,\n+\t\t * hence src_reg has to be precise.\n+\t\t */\n+\t\tif (BPF_SRC(insn-\u003ecode) == BPF_X) {\n+\t\t\terr = mark_chain_precision(env, insn-\u003esrc_reg);\n+\t\t\tif (err)\n+\t\t\t\treturn err;\n+\t\t}\n \t\t/* Mark all identical registers in each branch as either\n \t\t * safe or unknown depending R == 0 or R != 0 conditional.\n \t\t */\ndiff --git a/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c b/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c\nindex b412a542ef76f..3c789c565b18f 100644\n--- a/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c\n+++ b/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c\n@@ -311,6 +311,147 @@ __naked void untrusted_mem_does_not_infer_map_value_non_null(void)\n \t: __clobber_all);\n }\n \n+/*\n+ * A pointer with an offset that is not bounded from above may be null at\n+ * runtime, hence it is not a witness for the pointer it is compared with.\n+ */\n+SEC(\"socket\")\n+__failure\n+__msg(\"error: invalid dereference of R7 (a nullable map value pointer)\")\n+__naked void unbounded_offset_does_not_infer_map_value_non_null(void)\n+{\n+\tasm volatile (\"\t\t\t\t\t\\\n+\t/* r6 = bpf_map_lookup_elem(map_hash, \u00260); */\t\\\n+\t*(u64 *)(r10 - 8) = 0;\t\t\t\t\\\n+\tr1 = %[map_hash] ll;\t\t\t\t\\\n+\tr2 = r10;\t\t\t\t\t\\\n+\tr2 += -8;\t\t\t\t\t\\\n+\tcall %[bpf_map_lookup_elem];\t\t\t\\\n+\tif r0 == 0 goto 1f;\t\t\t\t\\\n+\tr6 = r0;\t\t\t\t\t\\\n+\t/* r7 = bpf_map_lookup_elem(map_hash, \u00261); */\t\\\n+\t*(u64 *)(r10 - 8) = 1;\t\t\t\t\\\n+\tr1 = %[map_hash] ll;\t\t\t\t\\\n+\tr2 = r10;\t\t\t\t\t\\\n+\tr2 += -8;\t\t\t\t\t\\\n+\tcall %[bpf_map_lookup_elem];\t\t\t\\\n+\tr7 = r0;\t\t\t\t\t\\\n+\t/* pointer - pointer is an unknown scalar */\t\\\n+\tr8 = r7;\t\t\t\t\t\\\n+\tr8 -= r6;\t\t\t\t\t\\\n+\t/* r8 is in [0, S64_MAX] */\t\t\t\\\n+\tr8 \u003c\u003c= 1;\t\t\t\t\t\\\n+\tr8 \u003e\u003e= 1;\t\t\t\t\t\\\n+\t/* r6 may wrap to zero at runtime */\t\t\\\n+\tr6 += r8;\t\t\t\t\t\\\n+\tif r7 != r6 goto 1f;\t\t\t\t\\\n+\tr0 = *(u8 *)(r7 + 0);\t\t\t\t\\\n+1:\tr0 = 0;\t\t\t\t\t\t\\\n+\texit;\t\t\t\t\t\t\\\n+\"\t:\n+\t: __imm(bpf_map_lookup_elem),\n+\t __imm_addr(map_hash)\n+\t: __clobber_all);\n+}\n+\n+/* Same, but the offset is bounded, so the inference is still done. */\n+SEC(\"socket\")\n+__success\n+__naked void bounded_offset_infers_map_value_non_null(void)\n+{\n+\tasm volatile (\"\t\t\t\t\t\\\n+\t/* r6 = bpf_map_lookup_elem(map_hash, \u00260); */\t\\\n+\t*(u64 *)(r10 - 8) = 0;\t\t\t\t\\\n+\tr1 = %[map_hash] ll;\t\t\t\t\\\n+\tr2 = r10;\t\t\t\t\t\\\n+\tr2 += -8;\t\t\t\t\t\\\n+\tcall %[bpf_map_lookup_elem];\t\t\t\\\n+\tif r0 == 0 goto 1f;\t\t\t\t\\\n+\tr6 = r0;\t\t\t\t\t\\\n+\t/* r7 = bpf_map_lookup_elem(map_hash, \u00261); */\t\\\n+\t*(u64 *)(r10 - 8) = 1;\t\t\t\t\\\n+\tr1 = %[map_hash] ll;\t\t\t\t\\\n+\tr2 = r10;\t\t\t\t\t\\\n+\tr2 += -8;\t\t\t\t\t\\\n+\tcall %[bpf_map_lookup_elem];\t\t\t\\\n+\tr7 = r0;\t\t\t\t\t\\\n+\t/* pointer - pointer is an unknown scalar */\t\\\n+\tr8 = r7;\t\t\t\t\t\\\n+\tr8 -= r6;\t\t\t\t\t\\\n+\t/* r8 is in [0, 3] */\t\t\t\t\\\n+\tr8 \u0026= 3;\t\t\t\t\t\\\n+\tr6 += r8;\t\t\t\t\t\\\n+\tif r7 != r6 goto 1f;\t\t\t\t\\\n+\tr0 = *(u8 *)(r7 + 0);\t\t\t\t\\\n+1:\tr0 = 0;\t\t\t\t\t\t\\\n+\texit;\t\t\t\t\t\t\\\n+\"\t:\n+\t: __imm(bpf_map_lookup_elem),\n+\t __imm_addr(map_hash)\n+\t: __clobber_all);\n+}\n+\n+/*\n+ * The low 32 bits of a map value pointer may be zero, hence a 32-bit\n+ * compare with zero cannot be predicted from the pointer being non-NULL\n+ * and both successors of such a jump have to be verified.\n+ */\n+SEC(\"socket\")\n+__failure __msg(\"invalid access to map value, value_size=4 off=32 size=4\")\n+__naked void jmp32_ptr_vs_zero_jne(void)\n+{\n+\tasm volatile (\"\t\t\t\t\t\\\n+\t/* r0 = bpf_map_lookup_elem(map_hash, \u0026key); */\t\\\n+\t*(u64 *)(r10 - 8) = 0;\t\t\t\t\\\n+\tr1 = %[map_hash] ll;\t\t\t\t\\\n+\tr2 = r10;\t\t\t\t\t\\\n+\tr2 += -8;\t\t\t\t\t\\\n+\tcall %[bpf_map_lookup_elem];\t\t\t\\\n+\tif r0 == 0 goto 1f;\t\t\t\t\\\n+\tif w0 != 0 goto 1f;\t\t\t\t\\\n+\tr0 = *(u32 *)(r0 + 32);\t\t\t\t\\\n+1:\tr0 = 0;\t\t\t\t\t\t\\\n+\texit;\t\t\t\t\t\t\\\n+\"\t:\n+\t: __imm(bpf_map_lookup_elem),\n+\t __imm_addr(map_hash)\n+\t: __clobber_all);\n+}\n+\n+/*\n+ * The below program is explored in two paths: r6 == 0 and r6 == 1.\n+ * On the first path comparison \"if r0 == r6 goto 2f\" should mark r6 as precise,\n+ * otherwise unsafe path with r6 == 1 would be incorrectly pruned.\n+ */\n+SEC(\"socket\")\n+__failure\n+__flag(BPF_F_TEST_STATE_FREQ)\n+__msg(\"error: invalid dereference of R0 (a nullable map value pointer)\")\n+__naked void imprecise_zero_does_not_infer_map_value_non_null(void)\n+{\n+\tasm volatile (\"\t\t\t\t\t\\\n+\tcall %[bpf_get_prandom_u32];\t\t\t\\\n+\t/* r6 is 0 on the path explored first, 1 on the other */\\\n+\tr6 = 1;\t\t\t\t\t\t\\\n+\tif r0 == 0 goto 1f;\t\t\t\t\\\n+\tr6 = 0;\t\t\t\t\t\t\\\n+\t/* r0 = bpf_map_lookup_elem(map_hash, \u00260); */\t\\\n+1:\t*(u64 *)(r10 - 8) = 0;\t\t\t\t\\\n+\tr1 = %[map_hash] ll;\t\t\t\t\\\n+\tr2 = r10;\t\t\t\t\t\\\n+\tr2 += -8;\t\t\t\t\t\\\n+\tcall %[bpf_map_lookup_elem];\t\t\t\\\n+\tif r0 == r6 goto 2f;\t\t\t\t\\\n+\tr0 = *(u8 *)(r0 + 0);\t\t\t\t\\\n+2:\tr0 = 0;\t\t\t\t\t\t\\\n+\texit;\t\t\t\t\t\t\\\n+\"\t:\n+\t: __imm(bpf_get_prandom_u32),\n+\t __imm(bpf_map_lookup_elem),\n+\t __imm_addr(map_hash)\n+\t: __clobber_all);\n+}\n+\n void kfunc_root(void)\n {\n \tbpf_rdonly_cast(0, 0);\ndiff --git a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c\nindex 663d15fc5fd26..256547048cc45 100644\n--- a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c\n+++ b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c\n@@ -380,13 +380,14 @@ SEC(\"socket\")\n __success __log_level(2)\n __flag(BPF_F_TEST_STATE_FREQ)\n /*\n- * check that r0 and r5 have different IDs after 'if',\n- * collect_linked_regs() can't tie more than 5 registers for a single insn.\n+ * check that r5 is unlinked after 'if', collect_linked_regs() can't tie\n+ * more than 5 registers for a single insn and the register compared by\n+ * the jump is not exempt from that.\n */\n-__msg(\"7: (25) if r0 \u003e 0x7 goto pc+0 ; R0=scalar(id=1\")\n+__msg(\"7: (25) if r5 \u003e 0x7 goto pc+0 ; R5=scalar(smin=\")\n __msg(\"12: (bf) r5 = r5 ; R5=scalar(id=2\")\n /* check that r{0-4} are marked precise after 'if' */\n-__msg(\"frame0: regs=r0 stack= before 7: (25) if r0 \u003e 0x7 goto pc+0\")\n+__msg(\"frame0: regs=r0 stack= before 7: (25) if r5 \u003e 0x7 goto pc+0\")\n __msg(\"frame0: parent state regs=r0,r1,r2,r3,r4 stack=:\")\n __naked void linked_regs_too_many_regs(void)\n {\n@@ -400,8 +401,8 @@ __naked void linked_regs_too_many_regs(void)\n \t\"r3 = r0;\"\n \t\"r4 = r0;\"\n \t\"r5 = r0;\"\n-\t/* propagate range for r{0-5} */\n-\t\"if r0 \u003e 7 goto +0;\"\n+\t/* r{0-4} fill the record, r5 does not fit and is unlinked */\n+\t\"if r5 \u003e 7 goto +0;\"\n \t/* keep r{1-4} live */\n \t\"r1 = r1;\"\n \t\"r2 = r2;\"\n"
} |
| 2/1 | 2026/09/05 17:38 | agent | patch-evaluator |
0mModel:core Args: null Results: {
"EnableConfigs": [
"BPF_SYSCALL"
],
"FocusSymbols": [
"check_cond_jmp_op",
"is_branch_taken",
"reg_not_null",
"bpf_check"
],
"Reasoning": "The patch modifies BPF verifier logic in kernel/bpf/verifier.c for pointer nullness inference, 32-bit jump branch prediction, linked registers collection timing, and precision tracking on register comparisons. These changes affect reachable verification paths when loading BPF programs via the bpf() system call and warrant fuzzing.",
"WorthFuzzing": true
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any '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.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit b4c5df61cfb59c520846e7be0f1827f2128897e6
Author: syz-cluster <triage@syzkaller.com>
Date: Sat Sep 5 17:38:01 2026 +0000
syz-cluster: applied patch under review
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e640356837951..709b4793e8eb7 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -352,6 +352,13 @@ static bool reg_not_null(struct bpf_verifier_env *env, const struct bpf_reg_stat
if (type_may_be_null(type))
return false;
+ /*
+ * The types below guarantee a non-NULL base, an unbounded offset can
+ * still wrap base + offset to zero.
+ */
+ if (reg_smin(reg) <= -BPF_MAX_VAR_OFF || reg_smax(reg) >= BPF_MAX_VAR_OFF)
+ return false;
+
type = base_type(type);
return type == PTR_TO_SOCKET ||
type == PTR_TO_TCP_SOCK ||
@@ -16302,6 +16309,13 @@ static int is_branch_taken(struct bpf_verifier_env *env, struct bpf_reg_state *r
if (__is_pointer_value(false, reg1) || __is_pointer_value(false, reg2)) {
u64 val;
+ /*
+ * The low 32 bits of a valid pointer may well be zero, hence
+ * nothing below applies to a 32-bit comparison.
+ */
+ if (is_jmp32)
+ return -1;
+
/* arrange that reg2 is a scalar, and reg1 is a pointer */
if (!is_reg_const(reg2, is_jmp32)) {
opcode = flip_opcode(opcode);
@@ -16863,6 +16877,16 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
return err;
}
+ /*
+ * Collect the linked registers before env->{true,false}_reg{1,2} setup,
+ * otherwise ids dropped by collect_linked_regs() would be resurrected
+ * when env->{true,false}_reg{1,2} are copied back.
+ */
+ if (BPF_SRC(insn->code) == BPF_X && src_reg->type == SCALAR_VALUE && src_reg->id)
+ collect_linked_regs(env, this_branch, src_reg->id, &linked_regs);
+ if (dst_reg->type == SCALAR_VALUE && dst_reg->id)
+ collect_linked_regs(env, this_branch, dst_reg->id, &linked_regs);
+
is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32;
env->false_reg1 = *dst_reg;
env->false_reg2 = *src_reg;
@@ -16917,10 +16941,6 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
* 'this_branch' and 'other_branch' share this history
* if parent state is created.
*/
- if (BPF_SRC(insn->code) == BPF_X && src_reg->type == SCALAR_VALUE && src_reg->id)
- collect_linked_regs(env, this_branch, src_reg->id, &linked_regs);
- if (dst_reg->type == SCALAR_VALUE && dst_reg->id)
- collect_linked_regs(env, this_branch, dst_reg->id, &linked_regs);
if (linked_regs.cnt > 1) {
err = bpf_push_jmp_history(env, this_branch, 0, 0, 0, linked_regs_pack(&linked_regs));
if (err)
@@ -17004,6 +17024,15 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
type_may_be_null(dst_reg->type) &&
((BPF_SRC(insn->code) == BPF_K && insn->imm == 0) ||
(BPF_SRC(insn->code) == BPF_X && bpf_register_is_null(src_reg)))) {
+ /*
+ * For BPF_X the zero is a property of this execution path,
+ * hence src_reg has to be precise.
+ */
+ if (BPF_SRC(insn->code) == BPF_X) {
+ err = mark_chain_precision(env, insn->src_reg);
+ if (err)
+ return err;
+ }
/* Mark all identical registers in each branch as either
* safe or unknown depending R == 0 or R != 0 conditional.
*/
diff --git a/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c b/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c
index b412a542ef76f..3c789c565b18f 100644
--- a/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c
+++ b/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c
@@ -311,6 +311,147 @@ __naked void untrusted_mem_does_not_infer_map_value_non_null(void)
: __clobber_all);
}
+/*
+ * A pointer with an offset that is not bounded from above may be null at
+ * runtime, hence it is not a witness for the pointer it is compared with.
+ */
+SEC("socket")
+__failure
+__msg("error: invalid dereference of R7 (a nullable map value pointer)")
+__naked void unbounded_offset_does_not_infer_map_value_non_null(void)
+{
+ asm volatile (" \
+ /* r6 = bpf_map_lookup_elem(map_hash, &0); */ \
+ *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == 0 goto 1f; \
+ r6 = r0; \
+ /* r7 = bpf_map_lookup_elem(map_hash, &1); */ \
+ *(u64 *)(r10 - 8) = 1; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ r7 = r0; \
+ /* pointer - pointer is an unknown scalar */ \
+ r8 = r7; \
+ r8 -= r6; \
+ /* r8 is in [0, S64_MAX] */ \
+ r8 <<= 1; \
+ r8 >>= 1; \
+ /* r6 may wrap to zero at runtime */ \
+ r6 += r8; \
+ if r7 != r6 goto 1f; \
+ r0 = *(u8 *)(r7 + 0); \
+1: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
+/* Same, but the offset is bounded, so the inference is still done. */
+SEC("socket")
+__success
+__naked void bounded_offset_infers_map_value_non_null(void)
+{
+ asm volatile (" \
+ /* r6 = bpf_map_lookup_elem(map_hash, &0); */ \
+ *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == 0 goto 1f; \
+ r6 = r0; \
+ /* r7 = bpf_map_lookup_elem(map_hash, &1); */ \
+ *(u64 *)(r10 - 8) = 1; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ r7 = r0; \
+ /* pointer - pointer is an unknown scalar */ \
+ r8 = r7; \
+ r8 -= r6; \
+ /* r8 is in [0, 3] */ \
+ r8 &= 3; \
+ r6 += r8; \
+ if r7 != r6 goto 1f; \
+ r0 = *(u8 *)(r7 + 0); \
+1: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
+/*
+ * The low 32 bits of a map value pointer may be zero, hence a 32-bit
+ * compare with zero cannot be predicted from the pointer being non-NULL
+ * and both successors of such a jump have to be verified.
+ */
+SEC("socket")
+__failure __msg("invalid access to map value, value_size=4 off=32 size=4")
+__naked void jmp32_ptr_vs_zero_jne(void)
+{
+ asm volatile (" \
+ /* r0 = bpf_map_lookup_elem(map_hash, &key); */ \
+ *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == 0 goto 1f; \
+ if w0 != 0 goto 1f; \
+ r0 = *(u32 *)(r0 + 32); \
+1: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
+/*
+ * The below program is explored in two paths: r6 == 0 and r6 == 1.
+ * On the first path comparison "if r0 == r6 goto 2f" should mark r6 as precise,
+ * otherwise unsafe path with r6 == 1 would be incorrectly pruned.
+ */
+SEC("socket")
+__failure
+__flag(BPF_F_TEST_STATE_FREQ)
+__msg("error: invalid dereference of R0 (a nullable map value pointer)")
+__naked void imprecise_zero_does_not_infer_map_value_non_null(void)
+{
+ asm volatile (" \
+ call %[bpf_get_prandom_u32]; \
+ /* r6 is 0 on the path explored first, 1 on the other */\
+ r6 = 1; \
+ if r0 == 0 goto 1f; \
+ r6 = 0; \
+ /* r0 = bpf_map_lookup_elem(map_hash, &0); */ \
+1: *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == r6 goto 2f; \
+ r0 = *(u8 *)(r0 + 0); \
+2: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_get_prandom_u32),
+ __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
void kfunc_root(void)
{
bpf_rdonly_cast(0, 0);
diff --git a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
index 663d15fc5fd26..256547048cc45 100644
--- a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
+++ b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
@@ -380,13 +380,14 @@ SEC("socket")
__success __log_level(2)
__flag(BPF_F_TEST_STATE_FREQ)
/*
- * check that r0 and r5 have different IDs after 'if',
- * collect_linked_regs() can't tie more than 5 registers for a single insn.
+ * check that r5 is unlinked after 'if', collect_linked_regs() can't tie
+ * more than 5 registers for a single insn and the register compared by
+ * the jump is not exempt from that.
*/
-__msg("7: (25) if r0 > 0x7 goto pc+0 ; R0=scalar(id=1")
+__msg("7: (25) if r5 > 0x7 goto pc+0 ; R5=scalar(smin=")
__msg("12: (bf) r5 = r5 ; R5=scalar(id=2")
/* check that r{0-4} are marked precise after 'if' */
-__msg("frame0: regs=r0 stack= before 7: (25) if r0 > 0x7 goto pc+0")
+__msg("frame0: regs=r0 stack= before 7: (25) if r5 > 0x7 goto pc+0")
__msg("frame0: parent state regs=r0,r1,r2,r3,r4 stack=:")
__naked void linked_regs_too_many_regs(void)
{
@@ -400,8 +401,8 @@ __naked void linked_regs_too_many_regs(void)
"r3 = r0;"
"r4 = r0;"
"r5 = r0;"
- /* propagate range for r{0-5} */
- "if r0 > 7 goto +0;"
+ /* r{0-4} fill the record, r5 does not fit and is unlinked */
+ "if r5 > 7 goto +0;"
/* keep r{1-4} live */
"r1 = r1;"
"r2 = r2;"
|
| 3/2 | 2026/09/05 17:38 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 6669 output: 31 thoughts: 517 Thoughts: **Analyzing the BPF Verifier Patch** Okay, let's break this down. My initial impression is that this patch is touching the BPF verifier, specifically within `kernel/bpf/verifier.c` and the associated selftests. The verifier, of course, is a critical component, executed whenever a BPF program is loaded via `bpf(BPF_PROG_LOAD, ...)`. So, it's definitely something that needs careful scrutiny. And the impact is immediately obvious, accessible through the `CONFIG_BPF_SYSCALL` option. This means it's potentially reachable by both unprivileged and privileged users in standard environments like QEMU or Google Compute Engine. Specifically, it looks like there are a few key areas of change: 1. In `reg_not_null`, there's a modification to how null pointer checks are performed related to offset bounds, specifically around `-BPF_MAX_VAR_OFF` and `BPF_MAX_VAR_OFF`. 2. `is_branch_taken` also has changes, which relates to null checks with pointer comparisons, particularly around `is_jmp32` (32 bit comparisons). 3. `check_cond_jmp_op` appears to be getting some significant rework. The `collect_linked_regs` function is being moved, and `mark_chain_precision` is being added in the pointer-vs-null checking logic when dealing with `BPF_X` source operand and the source register being null. The core of the matter is still the BPF verifier itself: `kernel/bpf/verifier.c`. My focus here needs to be the functions being touched. I'll need to confirm the entry points through `bpf_check` and their relationship to `reg_not_null`, `is_branch_taken`, and `check_cond_jmp_op`. I want to see how these changes flow through the core verifier logic. I'll use `grepper` or just directly examine the file to make sure I get the symbols and configs right. This patch seems focused, but its implications on pointer handling and conditional jumps in BPF programs could be substantial, so I need to go deeper into it. |
| 4/2 | 2026/09/05 17:38 | tool | grepper |
0mError:no matches Args: {
"Expression": "config BPF_SYSCALL",
"PathPrefix": "init/Kconfig"
}Results: {
"error": "no matches"
} |
| 5/2 | 2026/09/05 17:38 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 7710 output: 21 thoughts: 17 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Tracing the BPF_SYSCALL Definition** Okay, so I need to track down the definition of `BPF_SYSCALL` within the kernel configuration system. My immediate instinct is to start with `Kconfig`. That's where all the compile-time options are set, so `BPF_SYSCALL`, being a macro likely tied to a feature or functionality, *should* be defined in a `Kconfig` file somewhere. The challenge now is figuring out where that `Kconfig` is. I'll need to do some digging, probably using `grep` or similar tools, searching the source tree for references or definitions. I'm expecting it to be nested within a feature that has to be configured when the kernel is compiled. Once I locate the file, I can analyze the associated `Kconfig` options to understand the implications of enabling or disabling `BPF_SYSCALL` and, crucially, understand any dependencies it might have. This will give me the context I need to work with. |
| 6/2 | 2026/09/05 17:38 | tool | grepper |
0mArgs:{
"Expression": "config BPF_SYSCALL"
}Results: {
"Output": "kernel/bpf/Kconfig=25=menu \"BPF subsystem\"\nkernel/bpf/Kconfig-26-\nkernel/bpf/Kconfig:27:config BPF_SYSCALL\nkernel/bpf/Kconfig-28-\tbool \"Enable bpf() system call\"\n"
} |
| 7/2 | 2026/09/05 17:38 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 8063 output: 49 thoughts: 51 Thoughts: Okay, here's my take on those thoughts, framed as my own: **Digging into the BPF Verifier** Alright, I need to get a handle on how the BPF verifier is managing conditional jumps and register validity. My hunch is that a deep dive into the code will reveal some key details. Let's start with `kernel/bpf/verifier.c`. Specifically, I want to confirm whether functions like `reg_not_null`, `is_branch_taken`, and `check_cond_jmp_op` are defined with static linkage or if they are accessible globally within the verifier's scope. Their scope will influence how easily they can be re-used and extended. Beyond that, I need to trace their call sites. Understanding how these functions are *called* provides vital context for their functionality, and will allow me to assess the verifier's control flow and decision-making logic, particularly around conditional jumps and register state tracking. This information is key to understanding, and potentially optimizing, the BPF verifier's operation. |
| 8/2 | 2026/09/05 17:38 | tool | grepper |
0mArgs:{
"Expression": "(reg_not_null|is_branch_taken|check_cond_jmp_op)",
"PathPrefix": "kernel/bpf/verifier.c"
}Results: {
"Output": "kernel/bpf/verifier.c=58=static bool bpf_global_percpu_ma_set;\n--\nkernel/bpf/verifier.c-160- * PTR_TO_MAP_VALUE and the same register changes state to CONST_IMM in the false\nkernel/bpf/verifier.c:161: * branch. See check_cond_jmp_op().\nkernel/bpf/verifier.c-162- *\n--\nkernel/bpf/verifier.c=326=static void verbose_invalid_scalar(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-346-\nkernel/bpf/verifier.c:347:static bool reg_not_null(struct bpf_verifier_env *env, const struct bpf_reg_state *reg)\nkernel/bpf/verifier.c-348-{\n--\nkernel/bpf/verifier.c=16256=static int is_pkt_ptr_branch_taken(struct bpf_reg_state *dst_reg,\n--\nkernel/bpf/verifier.c-16302- */\nkernel/bpf/verifier.c:16303:static int is_branch_taken(struct bpf_verifier_env *env, struct bpf_reg_state *reg1,\nkernel/bpf/verifier.c-16304-\t\t\t struct bpf_reg_state *reg2, u8 opcode, bool is_jmp32)\n--\nkernel/bpf/verifier.c-16327-\nkernel/bpf/verifier.c:16328:\t\tif (!reg_not_null(env, reg1))\nkernel/bpf/verifier.c-16329-\t\t\treturn -1;\n--\nkernel/bpf/verifier.c=16746=static void sync_linked_regs(struct bpf_verifier_env *env, struct bpf_verifier_state *vstate,\n--\nkernel/bpf/verifier.c-16800-\nkernel/bpf/verifier.c:16801:static int check_cond_jmp_op(struct bpf_verifier_env *env,\nkernel/bpf/verifier.c-16802-\t\t\t struct bpf_insn *insn, int *insn_idx)\n--\nkernel/bpf/verifier.c-16894-\tenv-\u003etrue_reg2 = *src_reg;\nkernel/bpf/verifier.c:16895:\tpred = is_branch_taken(env, dst_reg, src_reg, opcode, is_jmp32);\nkernel/bpf/verifier.c-16896-\tif (pred \u003e= 0) {\nkernel/bpf/verifier.c-16897-\t\t/* If we get here with a dst_reg pointer type it is because\nkernel/bpf/verifier.c:16898:\t\t * above is_branch_taken() special cased the 0 comparison.\nkernel/bpf/verifier.c-16899-\t\t */\n--\nkernel/bpf/verifier.c-17008-\t\t\t/* src == dst \u0026\u0026 dst != NULL =\u003e src != NULL */\nkernel/bpf/verifier.c:17009:\t\t\tif (reg_not_null(env, dst_reg) \u0026\u0026 type_may_be_null(src_reg-\u003etype))\nkernel/bpf/verifier.c-17010-\t\t\t\tmark_ptr_not_null_reg(\u0026eq_branch_regs[insn-\u003esrc_reg]);\nkernel/bpf/verifier.c-17011-\t\t\t/* src == dst \u0026\u0026 src != NULL =\u003e dst != NULL */\nkernel/bpf/verifier.c:17012:\t\t\tif (reg_not_null(env, src_reg) \u0026\u0026 type_may_be_null(dst_reg-\u003etype))\nkernel/bpf/verifier.c-17013-\t\t\t\tmark_ptr_not_null_reg(\u0026eq_branch_regs[insn-\u003edst_reg]);\n--\nkernel/bpf/verifier.c=18107=static int do_check_insn(struct bpf_verifier_env *env, bool *do_print_state)\n--\nkernel/bpf/verifier.c-18193-\t\t}\nkernel/bpf/verifier.c:18194:\t\treturn check_cond_jmp_op(env, insn, \u0026env-\u003einsn_idx);\nkernel/bpf/verifier.c-18195-\t}\n"
} |
| 9/2 | 2026/09/05 17:38 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 9500 output: 34 thoughts: 24 Thoughts: Okay, let's dive into this. Here's my perspective on this specific line of inquiry: **Investigating `bpf_check` in the BPF Verifier** Alright, I'm thinking we need to broaden our scope a bit. While we've been examining other areas, I'm feeling a nagging sensation that we might be overlooking something crucial. Specifically, I'm now thinking we should really take a hard look at `bpf_check` within `kernel/bpf/verifier.c`. It's a key function in this whole BPF verification process, and if there's an issue manifesting, it's very likely tied to this particular area. Let's make sure we've explored that section thoroughly; it warrants immediate attention. My gut says it's likely linked. |
| 10/2 | 2026/09/05 17:38 | tool | grepper |
0mArgs:{
"Expression": "int bpf_check\\(",
"PathPrefix": "kernel/bpf/verifier.c"
}Results: {
"Output": "kernel/bpf/verifier.c=20896=static int bpf_prog_verify_signature(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-21012-\nkernel/bpf/verifier.c:21013:int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr,\nkernel/bpf/verifier.c-21014-\t struct bpf_log_attr *attr_log)\n"
} |
| 11/2 | 2026/09/05 17:38 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 9873 output: 138 thoughts: 422 Thoughts: **My Fuzzing Strategy: BPF Verifier** Okay, let's get down to brass tacks. I need to figure out what to target for fuzzing. First, I'm going to pull out the focus symbols. Looks like it's these functions: `check_cond_jmp_op`, `is_branch_taken`, `reg_not_null`, and `bpf_check`. Got it. Next, I need to confirm if there are any other functions that were modified in this patch. Based on my analysis, it seems like these were all touched: `reg_not_null`, `is_branch_taken`, `check_cond_jmp_op`, all located within `kernel/bpf/verifier.c`. `bpf_check` is the primary entry point for the verifier, and the other three functions are static and were modified. Okay. Now, let's assess the fuzzing worthiness. The BPF verifier is definitely a core subsystem—it's right there in BPF. The patch details modifications in range tracking, pointer nullness, branch prediction, register linking, and precision tracking. Significant stuff. Also, I can reach it via the `sys_bpf` syscall with `BPF_PROG_LOAD`. *Definitely* WorthFuzzing=true. No question. I should also check the `EnableConfigs`. The relevant one here is `BPF_SYSCALL`, under the "BPF subsystem" menu. Good, that's what I expected. Let's review the focus symbol rules to make sure I'm doing this right. The goal is to focus on specific, non-ubiquitous kernel functions, targeting functions directly modified or acting as direct caller entrypoints. The ones I've selected, `check_cond_jmp_op`, `is_branch_taken`, `reg_not_null`, and `bpf_check`, fit the bill perfectly. Finally, just a quick double-check on the diff and all modified files to make sure I haven't missed anything. Looks like the core changes are in `kernel/bpf/verifier.c`, with some associated self-tests in `tools/testing/selftests/bpf/...`. The self-tests are user-space, so I don't need any symbols from them. All clear. Time to call `set-results`. |
| 12/2 | 2026/09/05 17:38 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"BPF_SYSCALL"
],
"FocusSymbols": [
"check_cond_jmp_op",
"is_branch_taken",
"reg_not_null",
"bpf_check"
],
"Reasoning": "The patch modifies BPF verifier logic in kernel/bpf/verifier.c for pointer nullness inference, 32-bit jump branch prediction, linked registers collection timing, and precision tracking on register comparisons. These changes affect reachable verification paths when loading BPF programs via the bpf() system call and warrant fuzzing.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"BPF_SYSCALL"
],
"FocusSymbols": [
"check_cond_jmp_op",
"is_branch_taken",
"reg_not_null",
"bpf_check"
],
"Reasoning": "The patch modifies BPF verifier logic in kernel/bpf/verifier.c for pointer nullness inference, 32-bit jump branch prediction, linked registers collection timing, and precision tracking on register comparisons. These changes affect reachable verification paths when loading BPF programs via the bpf() system call and warrant fuzzing.",
"WorthFuzzing": true
} |
| 13/1 | 2026/09/05 17:38 | action | If |
0mArgs:{
"WorthFuzzing": true
}Results: null |
| 14/2 | 2026/09/05 17:38 | agent | kmsan-evaluator |
0mModel:core Args: null Results: {
"KMSANReasoning": "The patch modifies the BPF verifier's logic in `kernel/bpf/verifier.c` to fix soundness issues regarding register tracking, specifically:\n1. Handling offset wrapping to zero in `reg_not_null()`.\n2. Handling 32-bit pointer-vs-scalar comparisons in `is_branch_taken()`.\n3. Ensuring linked registers are collected before saving registers in `check_cond_jmp_op()`.\n4. Marking precision on `src_reg` when checking nullness in `check_cond_jmp_op()`.\n\nThese changes do not introduce or modify uninitialized memory handling, structure padding, uninitialized buffers, or copies to user space. The structures manipulated (such as `struct linked_regs`) are initialized properly (e.g., zero-initialized on declaration), and the changes solely affect verifier internal control-flow and register state logic. Any potential misbehavior prevented by these fixes relates to BPF verification soundness (e.g., out-of-bounds accesses, NULL dereferences), which is covered by KASAN and standard sanitizers. Therefore, dedicated KMSAN fuzzing is not required.",
"NeedsKMSAN": false
}Instruction: You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.
CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
a comprehensive suite of debugging tools and sanitizers, including KASAN
(out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
(locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
or page allocations) and kernel-to-user memory info-leaks.
Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.
Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.
Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
attributes, ioctl output arguments, socket options, or BPF buffers) where fields
or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
uninitialized bytes of existing buffers.
Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
dereferences, locking deadlocks, or use-after-free bugs (these are already caught
by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.
Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
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.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit b4c5df61cfb59c520846e7be0f1827f2128897e6
Author: syz-cluster <triage@syzkaller.com>
Date: Sat Sep 5 17:38:01 2026 +0000
syz-cluster: applied patch under review
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e640356837951..709b4793e8eb7 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -352,6 +352,13 @@ static bool reg_not_null(struct bpf_verifier_env *env, const struct bpf_reg_stat
if (type_may_be_null(type))
return false;
+ /*
+ * The types below guarantee a non-NULL base, an unbounded offset can
+ * still wrap base + offset to zero.
+ */
+ if (reg_smin(reg) <= -BPF_MAX_VAR_OFF || reg_smax(reg) >= BPF_MAX_VAR_OFF)
+ return false;
+
type = base_type(type);
return type == PTR_TO_SOCKET ||
type == PTR_TO_TCP_SOCK ||
@@ -16302,6 +16309,13 @@ static int is_branch_taken(struct bpf_verifier_env *env, struct bpf_reg_state *r
if (__is_pointer_value(false, reg1) || __is_pointer_value(false, reg2)) {
u64 val;
+ /*
+ * The low 32 bits of a valid pointer may well be zero, hence
+ * nothing below applies to a 32-bit comparison.
+ */
+ if (is_jmp32)
+ return -1;
+
/* arrange that reg2 is a scalar, and reg1 is a pointer */
if (!is_reg_const(reg2, is_jmp32)) {
opcode = flip_opcode(opcode);
@@ -16863,6 +16877,16 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
return err;
}
+ /*
+ * Collect the linked registers before env->{true,false}_reg{1,2} setup,
+ * otherwise ids dropped by collect_linked_regs() would be resurrected
+ * when env->{true,false}_reg{1,2} are copied back.
+ */
+ if (BPF_SRC(insn->code) == BPF_X && src_reg->type == SCALAR_VALUE && src_reg->id)
+ collect_linked_regs(env, this_branch, src_reg->id, &linked_regs);
+ if (dst_reg->type == SCALAR_VALUE && dst_reg->id)
+ collect_linked_regs(env, this_branch, dst_reg->id, &linked_regs);
+
is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32;
env->false_reg1 = *dst_reg;
env->false_reg2 = *src_reg;
@@ -16917,10 +16941,6 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
* 'this_branch' and 'other_branch' share this history
* if parent state is created.
*/
- if (BPF_SRC(insn->code) == BPF_X && src_reg->type == SCALAR_VALUE && src_reg->id)
- collect_linked_regs(env, this_branch, src_reg->id, &linked_regs);
- if (dst_reg->type == SCALAR_VALUE && dst_reg->id)
- collect_linked_regs(env, this_branch, dst_reg->id, &linked_regs);
if (linked_regs.cnt > 1) {
err = bpf_push_jmp_history(env, this_branch, 0, 0, 0, linked_regs_pack(&linked_regs));
if (err)
@@ -17004,6 +17024,15 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env,
type_may_be_null(dst_reg->type) &&
((BPF_SRC(insn->code) == BPF_K && insn->imm == 0) ||
(BPF_SRC(insn->code) == BPF_X && bpf_register_is_null(src_reg)))) {
+ /*
+ * For BPF_X the zero is a property of this execution path,
+ * hence src_reg has to be precise.
+ */
+ if (BPF_SRC(insn->code) == BPF_X) {
+ err = mark_chain_precision(env, insn->src_reg);
+ if (err)
+ return err;
+ }
/* Mark all identical registers in each branch as either
* safe or unknown depending R == 0 or R != 0 conditional.
*/
diff --git a/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c b/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c
index b412a542ef76f..3c789c565b18f 100644
--- a/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c
+++ b/tools/testing/selftests/bpf/progs/verifier_jeq_infer_not_null.c
@@ -311,6 +311,147 @@ __naked void untrusted_mem_does_not_infer_map_value_non_null(void)
: __clobber_all);
}
+/*
+ * A pointer with an offset that is not bounded from above may be null at
+ * runtime, hence it is not a witness for the pointer it is compared with.
+ */
+SEC("socket")
+__failure
+__msg("error: invalid dereference of R7 (a nullable map value pointer)")
+__naked void unbounded_offset_does_not_infer_map_value_non_null(void)
+{
+ asm volatile (" \
+ /* r6 = bpf_map_lookup_elem(map_hash, &0); */ \
+ *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == 0 goto 1f; \
+ r6 = r0; \
+ /* r7 = bpf_map_lookup_elem(map_hash, &1); */ \
+ *(u64 *)(r10 - 8) = 1; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ r7 = r0; \
+ /* pointer - pointer is an unknown scalar */ \
+ r8 = r7; \
+ r8 -= r6; \
+ /* r8 is in [0, S64_MAX] */ \
+ r8 <<= 1; \
+ r8 >>= 1; \
+ /* r6 may wrap to zero at runtime */ \
+ r6 += r8; \
+ if r7 != r6 goto 1f; \
+ r0 = *(u8 *)(r7 + 0); \
+1: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
+/* Same, but the offset is bounded, so the inference is still done. */
+SEC("socket")
+__success
+__naked void bounded_offset_infers_map_value_non_null(void)
+{
+ asm volatile (" \
+ /* r6 = bpf_map_lookup_elem(map_hash, &0); */ \
+ *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == 0 goto 1f; \
+ r6 = r0; \
+ /* r7 = bpf_map_lookup_elem(map_hash, &1); */ \
+ *(u64 *)(r10 - 8) = 1; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ r7 = r0; \
+ /* pointer - pointer is an unknown scalar */ \
+ r8 = r7; \
+ r8 -= r6; \
+ /* r8 is in [0, 3] */ \
+ r8 &= 3; \
+ r6 += r8; \
+ if r7 != r6 goto 1f; \
+ r0 = *(u8 *)(r7 + 0); \
+1: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
+/*
+ * The low 32 bits of a map value pointer may be zero, hence a 32-bit
+ * compare with zero cannot be predicted from the pointer being non-NULL
+ * and both successors of such a jump have to be verified.
+ */
+SEC("socket")
+__failure __msg("invalid access to map value, value_size=4 off=32 size=4")
+__naked void jmp32_ptr_vs_zero_jne(void)
+{
+ asm volatile (" \
+ /* r0 = bpf_map_lookup_elem(map_hash, &key); */ \
+ *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == 0 goto 1f; \
+ if w0 != 0 goto 1f; \
+ r0 = *(u32 *)(r0 + 32); \
+1: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
+/*
+ * The below program is explored in two paths: r6 == 0 and r6 == 1.
+ * On the first path comparison "if r0 == r6 goto 2f" should mark r6 as precise,
+ * otherwise unsafe path with r6 == 1 would be incorrectly pruned.
+ */
+SEC("socket")
+__failure
+__flag(BPF_F_TEST_STATE_FREQ)
+__msg("error: invalid dereference of R0 (a nullable map value pointer)")
+__naked void imprecise_zero_does_not_infer_map_value_non_null(void)
+{
+ asm volatile (" \
+ call %[bpf_get_prandom_u32]; \
+ /* r6 is 0 on the path explored first, 1 on the other */\
+ r6 = 1; \
+ if r0 == 0 goto 1f; \
+ r6 = 0; \
+ /* r0 = bpf_map_lookup_elem(map_hash, &0); */ \
+1: *(u64 *)(r10 - 8) = 0; \
+ r1 = %[map_hash] ll; \
+ r2 = r10; \
+ r2 += -8; \
+ call %[bpf_map_lookup_elem]; \
+ if r0 == r6 goto 2f; \
+ r0 = *(u8 *)(r0 + 0); \
+2: r0 = 0; \
+ exit; \
+" :
+ : __imm(bpf_get_prandom_u32),
+ __imm(bpf_map_lookup_elem),
+ __imm_addr(map_hash)
+ : __clobber_all);
+}
+
void kfunc_root(void)
{
bpf_rdonly_cast(0, 0);
diff --git a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
index 663d15fc5fd26..256547048cc45 100644
--- a/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
+++ b/tools/testing/selftests/bpf/progs/verifier_scalar_ids.c
@@ -380,13 +380,14 @@ SEC("socket")
__success __log_level(2)
__flag(BPF_F_TEST_STATE_FREQ)
/*
- * check that r0 and r5 have different IDs after 'if',
- * collect_linked_regs() can't tie more than 5 registers for a single insn.
+ * check that r5 is unlinked after 'if', collect_linked_regs() can't tie
+ * more than 5 registers for a single insn and the register compared by
+ * the jump is not exempt from that.
*/
-__msg("7: (25) if r0 > 0x7 goto pc+0 ; R0=scalar(id=1")
+__msg("7: (25) if r5 > 0x7 goto pc+0 ; R5=scalar(smin=")
__msg("12: (bf) r5 = r5 ; R5=scalar(id=2")
/* check that r{0-4} are marked precise after 'if' */
-__msg("frame0: regs=r0 stack= before 7: (25) if r0 > 0x7 goto pc+0")
+__msg("frame0: regs=r0 stack= before 7: (25) if r5 > 0x7 goto pc+0")
__msg("frame0: parent state regs=r0,r1,r2,r3,r4 stack=:")
__naked void linked_regs_too_many_regs(void)
{
@@ -400,8 +401,8 @@ __naked void linked_regs_too_many_regs(void)
"r3 = r0;"
"r4 = r0;"
"r5 = r0;"
- /* propagate range for r{0-5} */
- "if r0 > 7 goto +0;"
+ /* r{0-4} fill the record, r5 does not fit and is unlinked */
+ "if r5 > 7 goto +0;"
/* keep r{1-4} live */
"r1 = r1;"
"r2 = r2;"
|
| 15/3 | 2026/09/05 17:38 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 5881 output: 32 thoughts: 1217 Thoughts: **Analyzing the BPF Verifier Patch for KMSAN Relevance**
Alright, let's dive into this patch and determine if we need to consider KMSAN here. My initial thought is to go through the changes in `kernel/bpf/verifier.c` and selftests, focusing on the potential for uninitialized memory issues.
First, I'll examine the code changes in `kernel/bpf/verifier.c` in detail:
1. **`reg_not_null` change:** The addition of the offset check makes sense. We need to prevent unbounded offsets leading to potential null pointer dereferences, as a register that's *assumed* non-null can become null after applying an excessively large offset to it. This isn't inherently a KMSAN issue, but a critical soundness fix.
2. **`is_branch_taken` modification:** Ignoring the 32-bit comparison result in some cases is correct. The lower 32 bits of a valid pointer can be zero, so we can't assume a branch is taken if the comparison is zero. This seems like a sanity check, more of a safety fix, and does not pose a direct KMSAN risk.
3. **`check_cond_jmp_op` adjustments:** Moving the `collect_linked_regs` call before saving true/false register copies is crucial. The original order caused problems where `collect_linked_regs` might drop register IDs, and those dropped IDs get resurrected when we copy the saved `true/false` registers. It's a soundness fix, guarding against incorrect state restoration and possible memory corruption.
4. **`check_cond_jmp_op` addition:** Marking chain precision for `src_reg` when it's part of a branch condition, especially if the source register is scalar, is also a soundness fix. This prevents unsound state pruning during verification, critical for preventing bugs from being exploited.
Essentially, this patch is tightening up the BPF verifier logic to prevent potential soundness bugs. The verifier tracks pointers and scalars, ensuring that BPF programs are safe to execute.
Now, let's map this against KMSAN criteria. Does this touch any kernel structures passed to userspace via any of the standard methods, where uninitialized fields could be a problem? No, the variables the verifier deals with are internal verifier state structs, such as `linked_regs` and `env`, which are properly initialized. Does it introduce conditional logic or branching based on uninitialized variables? Nope, verifier structs are properly initialized. Does it mess with allocating or initializing complex data structures where uninitialized fields could be read later? Again, no. Is there any bounds check or length logic changed that allows surrounding code to access uninitialized bytes? Still no. The fixes are targeted at the verifier's internal state-tracking logic, aimed at preventing exploitable bugs.
These bugs would typically lead to arbitrary kernel memory read/write if exploited, a classic KASAN issue, or verifier state tracking issues. So, it is more like preventing security vulnerabilities, not KMSAN-related problems. The BPF verifier logic operates on initialized C structs.
I should double-check the initialization of `linked_regs` to be absolutely sure; were the structs `linked_regs` initialized with `struct linked_regs linked_regs = {};` or `struct bpf_reg_state false_reg1, false_reg2;`? Let me quickly grep for `check_cond_jmp_op` in `kernel/bpf/verifier.c` to confirm that `linked_regs` is being correctly initialized. Assuming they are initialized, then I think KMSAN isn't the primary concern here. KASAN is the most important check here.
|
| 16/3 | 2026/09/05 17:38 | tool | grepper |
0mArgs:{
"Expression": "struct linked_regs",
"PathPrefix": "kernel/bpf/verifier.c"
}Results: {
"Output": "kernel/bpf/verifier.c=3245=struct linked_reg {\n--\nkernel/bpf/verifier.c-3253-\nkernel/bpf/verifier.c:3254:struct linked_regs {\nkernel/bpf/verifier.c-3255-\tint cnt;\n--\nkernel/bpf/verifier.c-3258-\nkernel/bpf/verifier.c:3259:static struct linked_reg *linked_regs_push(struct linked_regs *s)\nkernel/bpf/verifier.c-3260-{\n--\nkernel/bpf/verifier.c-3274- */\nkernel/bpf/verifier.c:3275:static u64 linked_regs_pack(struct linked_regs *s)\nkernel/bpf/verifier.c-3276-{\n--\nkernel/bpf/verifier.c-3295-\nkernel/bpf/verifier.c:3296:static void linked_regs_unpack(u64 val, struct linked_regs *s)\nkernel/bpf/verifier.c-3297-{\n--\nkernel/bpf/verifier.c=3345=void bpf_bt_sync_linked_regs(struct backtrack_state *bt, struct bpf_jmp_history_entry *hist)\nkernel/bpf/verifier.c-3346-{\nkernel/bpf/verifier.c:3347:\tstruct linked_regs linked_regs;\nkernel/bpf/verifier.c-3348-\tbool some_precise = false;\n--\nkernel/bpf/verifier.c=16586=static bool try_match_pkt_pointers(const struct bpf_insn *insn,\n--\nkernel/bpf/verifier.c-16690-\nkernel/bpf/verifier.c:16691:static void __collect_linked_regs(struct linked_regs *reg_set, struct bpf_reg_state *reg,\nkernel/bpf/verifier.c-16692-\t\t\t\t u32 id, u32 frameno, u32 spi_or_reg, bool is_reg)\n--\nkernel/bpf/verifier.c=16713=static void collect_linked_regs(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-16715-\t\t\t\tu32 id,\nkernel/bpf/verifier.c:16716:\t\t\t\tstruct linked_regs *linked_regs)\nkernel/bpf/verifier.c-16717-{\n--\nkernel/bpf/verifier.c=16746=static void sync_linked_regs(struct bpf_verifier_env *env, struct bpf_verifier_state *vstate,\nkernel/bpf/verifier.c:16747:\t\t\t struct bpf_reg_state *known_reg, struct linked_regs *linked_regs)\nkernel/bpf/verifier.c-16748-{\n--\nkernel/bpf/verifier.c=16801=static int check_cond_jmp_op(struct bpf_verifier_env *env,\n--\nkernel/bpf/verifier.c-16808-\tstruct bpf_reg_state *eq_branch_regs;\nkernel/bpf/verifier.c:16809:\tstruct linked_regs linked_regs = {};\nkernel/bpf/verifier.c-16810-\tu8 opcode = BPF_OP(insn-\u003ecode);\n"
} |
| 17/3 | 2026/09/05 17:38 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 8797 output: 268 thoughts: 192 Thoughts: **My Assessment of the BPF Verifier Patch**
Okay, so I've been reviewing this patch, and here's my take. It starts by initializing `linked_regs` – that's straightforward enough: `{}`. The core of this is about BPF verifier logic, specifically ensuring it's correct. I see they're addressing several crucial areas:
* First, `reg_not_null` is getting a closer look for any bounds or overflow issues with pointer offsets. That's good; those can be nasty to track down later.
* Then, they're digging into the nuances of how jump pointer comparisons work, especially the 32-bit versus 64-bit behavior within `is_branch_taken`. This can get really hairy with pointer arithmetic, so thoroughness here is critical.
* They're also adjusting the timing of `collect_linked_regs` in relation to saving registers within `check_cond_jmp_op`. That's likely about ensuring the verifier has the right register state at the correct moment in the control flow. Timing errors can be really subtle.
* Finally, there's attention being paid to precision marking for `src_reg` during null comparisons. This is about making sure the verifier has a solid understanding of the register's potential value ranges, especially in cases where we're testing for null.
Now, the important part: I'm not seeing anything in these changes that touches uninitialized memory, exposes stack or heap data, or copies data to user space. That's a huge relief. The fixes, if they were in place to start with, are entirely within the realm of preventing memory safety issues like out-of-bounds reads/writes or null pointer dereferences. And frankly, those are already covered by KASAN and UB-sanitizer anyway, so we're covered.
Therefore, given the nature of the changes, this patch doesn't warrant a KMSAN scan. Let's call `set-results`.
|
| 18/3 | 2026/09/05 17:38 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch modifies the BPF verifier's logic in `kernel/bpf/verifier.c` to fix soundness issues regarding register tracking, specifically:\n1. Handling offset wrapping to zero in `reg_not_null()`.\n2. Handling 32-bit pointer-vs-scalar comparisons in `is_branch_taken()`.\n3. Ensuring linked registers are collected before saving registers in `check_cond_jmp_op()`.\n4. Marking precision on `src_reg` when checking nullness in `check_cond_jmp_op()`.\n\nThese changes do not introduce or modify uninitialized memory handling, structure padding, uninitialized buffers, or copies to user space. The structures manipulated (such as `struct linked_regs`) are initialized properly (e.g., zero-initialized on declaration), and the changes solely affect verifier internal control-flow and register state logic. Any potential misbehavior prevented by these fixes relates to BPF verification soundness (e.g., out-of-bounds accesses, NULL dereferences), which is covered by KASAN and standard sanitizers. Therefore, dedicated KMSAN fuzzing is not required.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch modifies the BPF verifier's logic in `kernel/bpf/verifier.c` to fix soundness issues regarding register tracking, specifically:\n1. Handling offset wrapping to zero in `reg_not_null()`.\n2. Handling 32-bit pointer-vs-scalar comparisons in `is_branch_taken()`.\n3. Ensuring linked registers are collected before saving registers in `check_cond_jmp_op()`.\n4. Marking precision on `src_reg` when checking nullness in `check_cond_jmp_op()`.\n\nThese changes do not introduce or modify uninitialized memory handling, structure padding, uninitialized buffers, or copies to user space. The structures manipulated (such as `struct linked_regs`) are initialized properly (e.g., zero-initialized on declaration), and the changes solely affect verifier internal control-flow and register state logic. Any potential misbehavior prevented by these fixes relates to BPF verification soundness (e.g., out-of-bounds accesses, NULL dereferences), which is covered by KASAN and standard sanitizers. Therefore, dedicated KMSAN fuzzing is not required.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|