Race connect() against sockmap update, while delivering signal. Do it for
different socket families and see what happens.
This is a long-due follow-up to [1], where John Fastabend asked for a more
generic and CI-fitting version of the selftest. Then, more recently in [2]
we've dealt with a af_vsock issue and circled back to the selftest.
Currently selftest exercises only {BPF_MAP_TYPE_SOCKMAP} x {AF_UNIX,
AF_VSOCK}. After reverting commit 002541ef650b ("vsock: Ignore
signal/timeout on connect() if already established") test, as expected,
triggers:
WARNING: net/vmw_vsock/vsock_bpf.c:90 at vsock_bpf_recvmsg+0x530/0x5a0, CPU#15:
test_progs/1487
RIP: 0010:vsock_bpf_recvmsg+0x530/0x5a0
Call Trace:
sock_recvmsg+0xbc/0xc0
__sys_recvfrom+0xb0/0x140
__x64_sys_recvfrom+0x20/0x30
do_syscall_64+0x95/0x510
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Following John's suggestion, I've added support for other protocols.
Torturing af_unix leads to a known null-ptr-deref discussed in [3]:
BUG: kernel NULL pointer dereference, address: 0000000000000080
RIP: 0010:unix_stream_bpf_update_proto+0x9c/0x1c0
Call Trace:
sock_map_link+0x564/0x8b0
sock_hash_update_common+0x6b/0x3c0
sock_map_update_elem_sys+0xd0/0x200
map_update_elem+0x235/0x570
__sys_bpf+0x150a/0x27e0
__x64_sys_bpf+0x1d/0x30
do_syscall_64+0x95/0x510
entry_SYSCALL_64_after_hwframe+0x76/0x7e
[1]: https://lore.kernel.org/netdev/[email protected]/
[2]:
https://lore.kernel.org/netdev/pstj7youxwwrpj3bl2a76kh2t62by2vdakv5elqvueobw3o4pj@tnknzlqdt344/
[3]: https://lore.kernel.org/netdev/[email protected]/
Signed-off-by: Michal Luczaj <[email protected]>
---
Michal Luczaj (2):
selftests/bpf: Add xpthread_cancel() to sockmap_helpers
selftests/bpf: Add test for connect() racing sockmap update and signal
.../selftests/bpf/prog_tests/sockmap_helpers.h | 9 +
.../bpf/prog_tests/sockmap_interrupted_connect.c | 200 +++++++++++++++++++++
2 files changed, 209 insertions(+)
---
base-commit: b015ba089d6bacacefd9daa247f8862795ba0467
change-id: 20251126-selftest-signal-on-connect-fd2fbf338c9c
Best regards,
--
Michal Luczaj <[email protected]>
