From: Eric Dumazet <edumazet@xxxxxxxxxx> commit 60ce37b03917e593d8e5d8bcc7ec820773daf81d upstream. Currently, sk_psock_verdict_recv() returns skb->len This is problematic because tcp_read_sock() might have passed orig_len < skb->len, due to the presence of TCP urgent data. This causes an infinite loop from tcp_read_sock() Followup patch will make tcp_read_sock() more robust vs bad actors. Fixes: ef5659280eb1 ("bpf, sockmap: Allow skipping sk_skb parser program") Reported-by: syzbot <syzkaller@xxxxxxxxxxxxxxxx> Signed-off-by: Eric Dumazet <edumazet@xxxxxxxxxx> Acked-by: John Fastabend <john.fastabend@xxxxxxxxx> Acked-by: Jakub Sitnicki <jakub@xxxxxxxxxxxxxx> Tested-by: Jakub Sitnicki <jakub@xxxxxxxxxxxxxx> Acked-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx> Link: https://lore.kernel.org/r/20220302161723.3910001-1-eric.dumazet@xxxxxxxxx Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- net/core/skmsg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -943,7 +943,7 @@ static int sk_psock_verdict_recv(read_de struct sk_psock *psock; struct bpf_prog *prog; int ret = __SK_DROP; - int len = skb->len; + int len = orig_len; /* clone here so sk_eat_skb() in tcp_read_sock does not drop our data */ skb = skb_clone(skb, GFP_ATOMIC); Patches currently in stable-queue which might be from edumazet@xxxxxxxxxx are queue-5.10/bpf-sockmap-do-not-ignore-orig_len-parameter.patch queue-5.10/net-fix-up-skbs-delta_truesize-in-udp-gro-frag_list.patch queue-5.10/netfilter-nf_queue-fix-possible-use-after-free.patch queue-5.10/netfilter-fix-use-after-free-in-__nf_register_net_hook.patch