radareorg/radare2-skills/ailogic

Introduction

Logic bugs are not syntax errors and the compiler will not catch them. They live in branches that look reasonable, in loops that almost terminate, and in assumptions that are never written down. This skill focuses on radare2's C codebase, where most logic bugs come from misuse of libr APIs, unchecked return values, and state that leaks across calls.

When this skill is used: read AGENTS.md first and follow the project rules. Patches must be surgical, behavior-preserving, and small.

Steps

1. Understand the function contract before reading the body

• What does each input represent? What range is valid?
• What must always be true on entry and on exit?
• If the contract is unclear, the function is already suspicious.

1. Identify inputs and boundaries

• Check handling of NULL, zero, negative, and UT64_MAX / UT32_MAX sentinels.
• Look for missing validation at R_API entry points (these should use R_RETURN_*).
• Static helpers should rely on the contract instead of re-checking.

1. Trace control flow with radare2

`` aaa pdf @ sym.function_name VV @ sym.function_name ``

• Follow every branch, including the implicit else.
• Watch for missing default: in switch, fallthrough without R_FALLTHROUGH, and early returns that skip cleanup.

1. Track variable state

• Where is each variable initialized, mutated, and consumed?
• Is it reused across iterations without reset?
• Use afvd to inspect locals and arguments.

1. Analyze loops

• Off-by-one: i <= size vs i < size.
• Termination: is the loop variable always advancing?
• Invariants: indices in bounds, pointers still valid, ownership unchanged.
• Clamp sizes once before the loop instead of re-checking inside.

1. Verify return values and error paths

• Are all r_* calls checked when they can fail (allocation, IO, parse)?
• Does every path return a meaningful value? Does failure free what success would have kept?
• Macros like R_NEW/R_NEW0 never return NULL (compile-time constant size), so do not add checks for them.
• Some mutators cannot report failure at all: RVec*_push_back and set_u_add return void and drop the element on OOM. Use RVec*_emplace_back and check the returned slot, or re-test with set_u_contains, wherever the caller's invariant needs the element to be present.
• A partially built table, set, or index is worse than none: on any element failure, free it and return the empty case, so callers fall back to their conservative path instead of trusting incomplete data.

1. Hunt silent assumptions

• "The list is non-empty", "the buffer is NUL-terminated", "the offset is aligned", "the seek will succeed".
• Each unchecked assumption is a candidate bug. Confirm it from the call sites, not from wishful thinking.

1. Confirm dynamically when possible

`` ood db sym.function_name dc dr; px `` Drive the suspect path with a real input and observe the state. A reproducer beats any amount of static reasoning.

1. Reduce to a minimal case

• Strip unrelated logic, build the smallest r2 oneliner or test that triggers it, then file or fix.

Common logic bug patterns in radare2

• Off-by-one on block size, instruction count, or string length
• Missing branch in a switch over an enum that grew a new value
• Boolean logic inverted after a refactor (! dropped or doubled)
• State not reset between calls because a static or core-> field leaks across invocations
• A scoped fact moved from a parameter onto long-lived state, then read after the branch that set it has ended
• Return value of r_io_read_at / r_buf_read_at ignored, partial reads treated as full
• r_core_cmd* return value ignored when the command can fail
• Seek not restored after a temporary r_core_seek; prefer call_at or the '@addr'cmd form
• Iterator invalidated mid-loop by r_list_delete instead of r_list_delete_iter
• CFG walk assuming reducible flow: handwritten and obfuscated code jumps into the middle of loops, so a backward walk from a back-edge escapes past the header and swallows unrelated blocks; bail out when the walk reaches a block that precedes the header
• Ownership confusion: same pointer freed on two paths, or freed by callee and caller
• Integer overflow on size * count before allocation

radare2 quick commands

aaa            # analyze all
pdf            # disassemble function
afvd           # show variables and arguments
VV             # visual graph
axt            # find xrefs to symbol
db / dc        # breakpoint / continue
dr / px        # registers / memory

Output

Write findings to a report file (default: ailogic-report.md) so the user can iterate on it while fixing. If the file exists, append new findings under a fresh dated section instead of overwriting; mark resolved entries with ✅ rather than deleting them, so progress is visible across runs.

Report structure

# ailogic report — YYYY-MM-DD
 
## Summary
1-2 sentences on what was audited (branch, files, functions) and the verdict:
✅ Clean / ⚠️ Issues found / ❌ Critical issues found
 
## Findings
<one @@@task block per finding, ordered by severity>

Task note format

Each finding is a @@@task block, mirroring aireview so the same tooling can consume both:

@@@task
# 🔴 Short title of the bug
 
The invariant or assumption that is violated, in at most 2 sentences.
 
## Trigger
The input, call sequence, or state that exercises the bug. Include an r2
oneliner reproducer when feasible.
 
## Suggested Commit Message
Short, capitalized, imperative. One line.
 
## Suggested Fix
What should change, surgically. Reference helpers to use (`r_list_delete_iter`,
`call_at`, `R_RETURN_*`, etc.) instead of describing rewrites.
 

filePath: libr/core/foo.c lineRange: 120...138 context: function_name

@@@

Severity: 🔴 high | 🟠 medium | 🟡 low

• HIGH CONFIDENCE ONLY. Skip anything you cannot justify from the code itself.
• One well-grounded finding beats a list of speculative ones — post zero if nothing holds up.
• Do not modify code from this skill; the report is the deliverable. Fixes are delegated.