Returning negative values repeatedly from a SOCK_FILTER ebpf prog stalls kernel thread

Returning negative values repeatedly from a SOCK_FILTER ebpf prog stalls kernel thread

[Zac Ecob]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Problem is title. Attached is files for repro. Working on v6.10-rc4. 

After doing some investigation, the `sk_wmem_alloc` member of `struct sk` seems to only be increasing, presumably missing some refcnt_dec somewhere.

At a certain point, in `sock_alloc_send_pskb`, we fail the check:

`
if (sk_wmem_alloc_get(sk) < READ_ONCE(sk->sk_sndbuf))
`

Upon which we enter `sock_wait_for_wmem` and schedule a massive timeout (at least that's what happened in my tests)


Please let me know if I need to add anything.

Thanks
Not sure where the missing refcnt subs are, must admit unfamiliarity with the network code.


[-- Attachment #2: repro.tar.xz --]
[-- Type: application/x-xz, Size: 2172 bytes --]

Returning negative values repeatedly from a SOCK_FILTER ebpf prog stalls kernel thread

[Zac Ecob]

Problem is title. 

To trigger, I attached an EBPF prof that just returned -1, and send ~1000 packets through it.

After doing some investigation, the `sk_wmem_alloc` member of `struct sk` seems to only be increasing, presumably missing some refcnt_dec somewhere. 

At a certain point, in `sock_alloc_send_pskb`, we fail the check: 

`
if (sk_wmem_alloc_get(sk) < READ_ONCE(sk->sk_sndbuf))
` 

Upon which we enter `sock_wait_for_wmem` and schedule a massive timeout (at least that's what happened in my tests).

Not sure where the missing refcnt subs are, must admit unfamiliarity with the network code.

Please let me know if I need to add anything. 

Thanks

Re: Returning negative values repeatedly from a SOCK_FILTER ebpf prog stalls kernel thread

[Kuniyuki Iwashima]

From: Zac Ecob <zacecob@protonmail.com>
Date: Sat, 22 Jun 2024 12:20:05 +0000
> Problem is title.
> 
> To trigger, I attached an EBPF prof that just returned -1, and send ~1000
> packets through it.

If you want to drop the packet, the prog must return 0.

You can see sk_filter_trim_cap() where the returned value from bpf prog
is cast to unsigned int.  Then, pskb_trim() does nothing because skb->len
is smaller than (unsigned int)-1, and 0 is set to err.

  unsigned int pkt_len;

  pkt_len = bpf_prog_run_save_cb(filter->prog, skb);
  err = pkt_len ? pskb_trim(skb, max(cap, pkt_len)) : -EPERM;

After calling sk_filter() from unix_dgram_sendmsg(), the skb is just queued
to the peer.


> 
> After doing some investigation, the `sk_wmem_alloc` member of `struct sk`
> seems to only be increasing, presumably missing some refcnt_dec somewhere.

So, no refcnt is leaked.
What is missing is recv() on the peer side.


> 
> At a certain point, in `sock_alloc_send_pskb`, we fail the check: 
> 
> `
> if (sk_wmem_alloc_get(sk) < READ_ONCE(sk->sk_sndbuf))
> ` 
> 
> Upon which we enter `sock_wait_for_wmem` and schedule a massive timeout
> (at least that's what happened in my tests).
> 
> Not sure where the missing refcnt subs are, must admit unfamiliarity with
> the network code.

The paired sub is sock_wfree() in unix_destruct_scm(), which is set
to skb->destructor() in unix_scm_to_skb() and called from kfree_skb().


> 
> Please let me know if I need to add anything. 
> 
> Thanks