diff options
| author | Paul Buetow <paul@buetow.org> | 2026-05-29 11:00:30 +0300 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2026-05-29 11:00:30 +0300 |
| commit | 49662fd127b9d9db062a052a5249750a1fc1b8a3 (patch) | |
| tree | e1b16ede061968b2185e1e381134687eb2bbec18 /integrationtests/security_test.go | |
| parent | 6561d63e5a47092d8b8f2a8128ad05ca9ffd2203 (diff) | |
test(generate): lock in madvise BPF handler field wiring
Audit of madvise(2) (int madvise(void *addr, size_t length, int advice))
confirmed the existing classification and BPF wiring are correct: KindMem /
FamilyMemory, addr=args[0], length=args[1], advice (flags-like) at args[2],
length2=0, and the int return captured generically as UNCLASSIFIED. This is
correctly distinct from process_madvise(2) (KindFd, pidfd at args[0]).
Unlike its KindMem siblings (mprotect, mlock2, brk, map_shadow_stack), madvise
lacked a dedicated handler-field lock-in test. Add TestGenerateMemHandlerMadvise
with positive field assertions plus negative guards: advice must come from
args[2] (not args[0]/addr), length2 must stay zero (no second region), and the
exit must return ctx->ret as UNCLASSIFIED.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diffstat (limited to 'integrationtests/security_test.go')
0 files changed, 0 insertions, 0 deletions
