netdev - Re: Fw: Linux tcp_xmit_retransmit_queue use after free on 4.8-rc1 / master]

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]

Message-ID: <CAM_iQpXV-jV0FsAzxt4JYrc6d5LCCLt-5_0uMvM49sV8-+SDDQ@mail.gmail.com>
Date:	Tue, 16 Aug 2016 13:19:13 -0700
From:	Cong Wang <xiyou.wangcong@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Marco Grassi <marco.gra@...il.com>,
	Yuchung Cheng <ycheng@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>
Subject: Re: Fw: Linux tcp_xmit_retransmit_queue use after free on 4.8-rc1 / master]

On Tue, Aug 16, 2016 at 11:39 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Tue, 2016-08-16 at 08:39 -0700, Eric Dumazet wrote:
>> On Tue, 2016-08-16 at 12:45 +0200, Greg KH wrote:
>> > For some reason Marco's emails can't make it to netdev, so I'm
>> > forwarding this on.  Please cc: him on responses.
>>
>> Thanks for the report Greg and Marco.
>>
>> My first guess is this is caused by
>>
>> d41a69f1d390 tcp: make tcp_sendmsg() aware of socket backlog
>>
>> And a combination of funky sendmsg() flags (like FastOpen)
>>
>> I will look at this problem today.
>>
>
> No, above commit was innocent ;)
>
> It looks like the bug is very old, and following patch would fix it.
> I will submit it formally after few tests.
>
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index c00e7d51bb18..7717302cab91 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1523,6 +1523,8 @@ static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unli
>  {
>         if (sk->sk_send_head == skb_unlinked)
>                 sk->sk_send_head = NULL;
> +       if (tcp_sk(sk)->highest_sack == skb_unlinked)
> +               tcp_sk(sk)->highest_sack = NULL;
>  }

Hmm, but from the stack traces it indicates the skb is freed
inside tcp_sendmsg(), which must be:


do_fault:
        if (!skb->len) {
                tcp_unlink_write_queue(skb, sk);
                /* It is the one place in all of TCP, except connection
                 * reset, where we can be unlinking the send_head.
                 */
                tcp_check_send_head(sk, skb);
                sk_wmem_free_skb(sk, skb);
        }

In this case, skb->len == 0 means it is newly allocated skb by
sk_stream_alloc_skb(), so it should not have a chance to be
picked by tp->highest_sack yet b/c the whole function locks
the sock?

I must miss something here.