Don't fuzz a module's own mutex: fusil was releasing it

[devdanzin]

The bug

PyPy implements grp in Python over cffi with a module-level mutex, and getgrall() holds it across its loop over libc's static group buffer:

_lock = _thread.allocate_lock()

def getgrall():
    with _lock:
        lib.setgrent()
        while 1:
            p = lib.getgrent()                    # -> libc's STATIC buffer
            if not p: break
            lst.append(_group_from_gstruct(p))    # walks p.gr_mem[i] until NULL

That lock is the only thing making the iteration safe. fusil selected grp._lock as a module-level object — it's just an attribute — and fuzzed it:

--- Fuzzing instance: fuzz_target_module._lock (type hint: lock, prefix: obj0m) ---
[obj0m11] lock.release_lock()
[obj0m12] lock.release_lock()

Release it mid-getgrall(), a second thread re-enters and calls setgrent()/getgrnam(), libc reuses the buffer under the first thread's feet, and while res.gr_mem[i]: walks freed memory.

	result
concurrent getgrall() + _lock.release_lock()	6/6 SIGSEGV in _group_from_gstruct
same concurrency, lock intact	6/6 clean

Necessary and sufficient. This is the grp crash open since the fleet_08 triage, left INCONCLUSIVE there because 22 of 24 replays timed out — releasing a lock hangs the harness as readily as it crashes it, which is why replay never worked.

Why METHOD_BLACKLIST didn't stop it

The shape of the gap is worth recording:

take a lock		drop a lock
acquire	BLOCKED	release	allowed
acquire_lock	BLOCKED	release_lock	allowed
_acquire_lock	BLOCKED	_release_lock	allowed
_acquire_restore	BLOCKED	_release_save	allowed
wait	BLOCKED	_at_fork_reinit	allowed

fusil had blocked the methods that hang it and left the ones that corrupt the target.

The fix

Filter on the object's type, at selection time, and only for module attributes. A lock fusil instantiated itself is nobody's mutex, so fuzzing threading still covers Lock/RLock/Condition through the class path. A name-based ban on release would instead have cost memoryview.release() — the surface PYPY-FUZZ-011 came from.

It has to hold on both discovery paths: in --discover-in-target mode the runner only sees a proxy carrying the type's name, so the target subprocess filters too — mirroring how TRIVIAL_TYPES is already split across the two.

Verified against the real module. Introspecting PyPy's grp now yields ['__loader__', '__spec__', 'ffi'] — no _lock.

Tests

Five, using real stdlib locks (tempfile._once_lock, logging._lock) on both paths, plus over-filtering guards: a lock fusil made itself is still a fuzz target, the class isn't skipped, and ordinary module objects survive. They set test_private=True as the PyPy fleets do — otherwise the underscore-prefixed names are filtered before the type is looked at and the test proves nothing. Four of five fail without the fix.

1308 tests pass; ruff check + ruff format --check clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WPBSmN87d2BqUnrDbojUT1