netdev - Re: [PATCH net] tcp: fastopen: avoid negative sk_forward

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Sep 2016 14:48:06 -0500
From:   Josh Hunt <johunt@...mai.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     netdev <netdev@...r.kernel.org>, Jerry Chu <hkchu@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [PATCH net] tcp: fastopen: avoid negative sk_forward_alloc

On 09/07/2016 10:34 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@...gle.com>
>
> When DATA and/or FIN are carried in a SYN/ACK message or SYN message,
> we append an skb in socket receive queue, but we forget to call
> sk_forced_mem_schedule().
>
> Effect is that the socket has a negative sk->sk_forward_alloc as long as
> the message is not read by the application.
>
> Josh Hunt fixed a similar issue in commit d22e15371811 ("tcp: fix tcp
> fin memory accounting")
>
> Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> ---
>   net/ipv4/tcp_fastopen.c |    1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
> index 62a5751d4fe1..4e777a3243f9 100644
> --- a/net/ipv4/tcp_fastopen.c
> +++ b/net/ipv4/tcp_fastopen.c
> @@ -150,6 +150,7 @@ void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb)
>   	tp->segs_in = 0;
>   	tcp_segs_in(tp, skb);
>   	__skb_pull(skb, tcp_hdrlen(skb));
> +	sk_forced_mem_schedule(sk, skb->truesize);
>   	skb_set_owner_r(skb, sk);
>
>   	TCP_SKB_CB(skb)->seq++;
>
>

The change makes sense to me. Thanks Eric!

Reviewed-by: Josh Hunt <johunt@...mai.com>