After a vsock socket has been added to a BPF sockmap, its prot->recvmsg
has been replaced with vsock_bpf_recvmsg(). Thus the following
recursiion could happen:
vsock_bpf_recvmsg()
-> __vsock_recvmsg()
-> vsock_connectible_recvmsg()
-> prot->recvmsg()
-> vsock_bpf_recvmsg() again
We need to fix it by calling the original ->recvmsg() without any BPF
sockmap logic in __vsock_recvmsg().
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Reported-by: syzbot+bdb4bd87b5e22058e2a4@syzkaller.appspotmail.com
Tested-by: syzbot+bdb4bd87b5e22058e2a4@syzkaller.appspotmail.com
Cc: Bobby Eshleman <bobby.eshleman@bytedance.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Cong Wang <cong.wang@bytedance.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://patch.msgid.link/20240812022153.86512-1-xiyou.wangcong@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
||
|---|---|---|
| .. | ||
| af_vsock_tap.c | ||
| af_vsock.c | ||
| diag.c | ||
| hyperv_transport.c | ||
| Kconfig | ||
| Makefile | ||
| virtio_transport_common.c | ||
| virtio_transport.c | ||
| vmci_transport_notify_qstate.c | ||
| vmci_transport_notify.c | ||
| vmci_transport_notify.h | ||
| vmci_transport.c | ||
| vmci_transport.h | ||
| vsock_addr.c | ||
| vsock_bpf.c | ||
| vsock_loopback.c | ||