On 8/1/25 2:49 AM, Paul Chaignon wrote:
We've already had two "error during ctx access conversion" warnings
triggered by syzkaller. Let's improve the error message by dumping the
cnt variable so that we can more easily differentiate between the
different error cases.
Signed-off-by: Paul Chaignon <paul.chaignon@xxxxxxxxx>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 399f03e62508..0806295945e4 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -21445,7 +21445,7 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
&target_size);
if (cnt == 0 || cnt >= INSN_BUF_SIZE ||
(ctx_field_size && !target_size)) {
- verifier_bug(env, "error during ctx access conversion");
+ verifier_bug(env, "error during ctx access conversion (%d)", cnt);
For the above, users still will not know what '(%d)' mean. So if we want to
provide better verification measure, we should do
if (cnt == 0 || cnt >= INSN_BUF_SIZE) {
verifier_bug(env, "error during ctx access conversion (insn cnt %d)", cnt);
return -EFAULT;
} else if (ctx_field_size && !target_size) {
verifier_bug(env, "error during ctx access conversion (ctx_field_size %d, target_size 0)", ctx_field_size);
return -EFAULT;
}
Another thing. The current log message is:
verifier bug: error during ctx access conversion (0)(1)
The '(0)' corresponds to insn cnt. The same one is due to the following:
#define verifier_bug_if(cond, env, fmt, args...) \
({ \
bool __cond = (cond); \
if (unlikely(__cond)) { \
BPF_WARN_ONCE(1, "verifier bug: " fmt "(" #cond ")\n", ##args); \
bpf_log(&env->log, "verifier bug: " fmt "(" #cond ")\n", ##args); \
} \
(__cond); \
})
#define verifier_bug(env, fmt, args...) verifier_bug_if(1, env, fmt, ##args)
Based on the above, the error message '(1)' is always there, esp. for verifier_bug(...) case?
Does this make sense?
return -EFAULT;
}
