From: 성병찬 <[email protected]>

Hi Bradley,

Thank you for testing the series and for the detailed feedback.

I reproduced the repeated-run problem and found that the test was rejecting
valid unsolicited exit notifications after the first one.  The kernel uses
an increasing per-CPU nlmsg_seq for these notifications; run 1 used sequence
zero, while later runs used nonzero sequences that receive_victim() silently
discarded.  The normal init_net listener therefore appeared silent for the
same userspace reason even though unicast succeeded.

The test now distinguishes matched, unmatched, expected-no-record, poll
timeout, deadline expiry, malformed, receive-error, socket-error, and
suspected-drop outcomes.  It reports receive counters and per-socket
/proc/net/netlink diagnostics, including Drops.  I also made registration,
victim exit, deregistration, close, and reap ordering explicit, added bounded
cooperative cleanup, and made closed-pipe cleanup SIGPIPE-safe.

I ran the same test binary 20 times back-to-back on one vulnerable boot.
Every run delivered the exact victim record to the colliding unprivileged
init_net socket instead of the child-netns registrar, while the normal
administrator and negative controls behaved as expected.  I then ran it 20
times back-to-back on each of two fixed boots; all 40 runs passed.  After
four induced failure modes, the post-failure recovery test passed 10/10.

I also repeated the validation on current mainline: the vulnerable kernel
reproduced 10/10, two fixed boots passed 20/20 each, and post-failure
recovery passed 10/10.

I added comments documenting the socket-private namespace lifetime and the
intentional all-CPU listener sweep during socket destruction.

I will send v4 as a separate series after allowing time for review.

Thanks,
Sung Byeongchan

Reply via email to