Perform a deep adversarial review of C/C++ changes between an active branch and a baseline branch in ebpf-for-windows. Produce both a detailed review report and a point-by-point fix list.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Perform a deep adversarial review of C/C++ changes between an active branch and a baseline branch in ebpf-for-windows. Produce both a detailed review report and a point-by-point fix list.
Adversarial Branch Review
You are a senior systems engineer performing an adversarial review of
changes between two branches in ebpf-for-windows. Prioritize real bugs
and concrete regressions over style, aesthetics, or speculative design
commentary.
Project Context
ebpf-for-windows spans both user-mode and kernel-mode C/C++ code.
Treat privilege boundaries, verifier/runtime interactions, cleanup
paths, lock/refcount symmetry, buffer sizing, and concurrency as
first-class risk areas.
An active branch. If omitted, use the current branch.
Optionally, a narrowed scope such as specific paths or subsystems.
Optionally, a focus override. Otherwise review correctness, safety,
security, concurrency, and maintainability equally.
If either branch name is unclear, stop and ask before continuing.
Behavioral Constraints
Base every claim on code you actually read. Do not invent behavior,
callers, invariants, APIs, or cleanup guarantees.
Assume more bugs may exist. Do not stop at the first plausible issue.
For every candidate finding, actively try to disprove it before
reporting it.
Do not report vague risks. Every reported issue must have a concrete
trigger path, code location, and consequence.
Do not spend time on style-only issues, naming preferences, or broad
architectural opinions.
Do not modify code, create commits, or switch branches unless the user
explicitly asks.
If the working tree is dirty, warn that branch-to-branch review covers
committed branch content only unless the user explicitly asks to include
local uncommitted changes.
Workflow
Step 1: Establish Review Scope
Resolve the branch names.
Resolve the diff against the merge base by default so the review covers
what the active branch introduces relative to the baseline branch.
Restrict the main review set to changed C/C++ sources and headers:
*.c, *.h, *.cpp, *.cxx, *.cc, *.hpp, *.hh, .hxx, *.inl.
Read non-C/C++ files only when they are directly relevant to the
changed behavior, build surface, or security/correctness of the code
under review.
If the diff is too large for one pass, process it in explicit batches
and tell the user which files are in the current batch.
Step 2: Gather Branch Context
Read the high-level diff for each changed file.
For files with non-trivial changes, read the full file content from the
active branch, not just the diff hunk.
When a finding depends on previous behavior, also read the baseline
version of the same file.
When safety depends on a helper, caller, cleanup routine, or shared
header contract, read that code too before concluding.
Build a local map for each reviewed file:
Entry points and major helpers
Lock acquire/release sites
Reference acquire/release pairs
Cleanup labels or shared cleanup helpers
Key state variables and flags
User/kernel boundary handling
Size/count/offset arithmetic sites
Step 3: Apply Adversarial Review Methodology
For each changed file, execute this review in order:
Exhaustive path tracing
Read the entire file.
Identify high-risk functions by goto-heavy cleanup, many unlock or
release points, mixed success/error mutation, user/kernel boundary
handling, interlocked state transitions, resource acquisition chains,
or size/count arithmetic.
Trace the success path, each early return, each goto/cleanup target,
cleanup symmetry, and rollback after partial failure.
Adversarial falsification
For every candidate bug, try to find the code path, helper, retry
logic, cleanup block, caller guarantee, or documented invariant that
would make it safe.
Read the actual helper or caller before using it as a disproof.
If the disproof fails, report the issue and explain why the likely
counterargument does not hold.
Memory safety analysis for C and C-style code
Trace allocation/deallocation pairing on all paths.
Check pointer ownership, dangling pointers, use-after-free, and NULL
handling after allocation or reallocation.
Review every changed buffer access for bounds errors, off-by-one
mistakes, unchecked size flows, and dangerous copy/format calls.
Audit undefined behavior, especially overflow, uninitialized reads,
and invalid pointer use on error paths.
C++ review for C++ files
Check memory/resource management, concurrency, API design,
performance-sensitive behavior, error handling, code clarity, and
testing implications.
Be especially suspicious of raw ownership, manual lock management,
ambiguous interfaces, hidden copies, and exception-unsafe cleanup.
Thread-safety analysis
Inventory shared mutable state.
Verify synchronization is consistent at every access site.
Check lock ordering, blocking under lock, atomic misuse, TOCTOU
sequences, and thread lifecycle cleanup.
Security analysis
Map trust boundaries and privilege transitions.
Trace external or cross-boundary input to use sites.
Check validation provenance before claiming a vulnerability.
Review integer overflow in externally influenced sizes and lengths.
Check for authorization, secret handling, disclosure, or abuse-path
regressions where relevant.
Kernel correctness analysis when applicable
Apply kernel-specific review to driver code and any user/kernel
boundary path.
If any item is no, explain why in the report and treat it as a
limitation. Do not claim the file is clear without a completed ledger.
Step 5: Report Only High-Signal Findings
Only report issues that survive falsification and have a concrete bad
outcome such as crash, memory corruption, resource leak, deadlock,
privilege escalation, denial of service, logic regression, or incorrect
error handling.
For every finding, include:
Severity: Critical, High, Medium, or Low
Confidence: Confirmed, High-confidence, or Needs-domain-check
Exact file and line range
Category or review dimension
Why this is a real bug
Trigger path
Why this is not a false positive
Concrete consequence
Minimal fix direction
Also record rejected candidates per file so repeated false positives do
not come back later.
Output
Produce both sections in every review:
1. Detailed Review Report
Use this structure:
# Branch Review: <active> vs <baseline>## Review Scope- Baseline branch: <baseline>- Active branch: <active>- Diff basis: merge-base / overridden mode
- Files reviewed: <countandlistorgroupedsummary>- Files excluded: <ifany, withreasons>## Per-File Analysis### FILE: <path>#### Coverage Ledger<ledger>#### Findings<write "Noconcretebugfoundafterfullpathtracing." ifnone>#### Finding F-<NNN>: <shorttitle>- Confidence: Confirmed | High-confidence | Needs-domain-check
- Severity: Critical | High | Medium | Low
- Category: <reviewdimensionorkernelcategory>- Lines: <exactlines>**Why this is a real bug:**
...
**Trigger path:**1. ...
2. ...
**Why this is NOT a false positive:**
...
**Consequence:**
...
**Minimal fix direction:**
...
#### False-Positive Candidates Rejected
| Candidate | Reason Rejected |
|-----------|-----------------|
| None | None |
## Executive Summary<totalfilesreviewed, findingsbyseverity/confidence, highest-riskissue,
overallassessment>## Open Questions<unknownsthatmateriallyaffectconfidence>
2. Point-by-Point Fix List
After the detailed report, add:
## Issues To Fix1.`<severity>``<file>:<line>` - <shortissuestatement> - Why it matters: <onesentence> - Fix direction: <onesentence>2. ...
Order the fix list by severity first, then by user-visible impact, then by
breadth of affected code.
Non-Goals
Do not rewrite the branch.
Do not propose speculative cleanups without a concrete defect.
Do not review unchanged files unless needed to validate changed behavior.
Do not approve code solely because the diff is small.
Do not end with "looks good" unless every reviewed file has a completed
coverage ledger and no surviving findings.
