Re: [PATCH net] tcp: Fix potential use-after-free due to double kfree().

From: Eric Dumazet
Date: Wed Jan 20 2021 - 08:18:55 EST


On Wed, Jan 20, 2021 at 2:17 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Mon, 18 Jan 2021 14:59:20 +0900 Kuniyuki Iwashima wrote:
> > Receiving ACK with a valid SYN cookie, cookie_v4_check() allocates struct
> > request_sock and then can allocate inet_rsk(req)->ireq_opt. After that,
> > tcp_v4_syn_recv_sock() allocates struct sock and copies ireq_opt to
> > inet_sk(sk)->inet_opt. Normally, tcp_v4_syn_recv_sock() inserts the full
> > socket into ehash and sets NULL to ireq_opt. Otherwise,
> > tcp_v4_syn_recv_sock() has to reset inet_opt by NULL and free the full
> > socket.
> >
> > The commit 01770a1661657 ("tcp: fix race condition when creating child
> > sockets from syncookies") added a new path, in which more than one cores
> > create full sockets for the same SYN cookie. Currently, the core which
> > loses the race frees the full socket without resetting inet_opt, resulting
> > in that both sock_put() and reqsk_put() call kfree() for the same memory:
> >
> > sock_put
> > sk_free
> > __sk_free
> > sk_destruct
> > __sk_destruct
> > sk->sk_destruct/inet_sock_destruct
> > kfree(rcu_dereference_protected(inet->inet_opt, 1));
> >
> > reqsk_put
> > reqsk_free
> > __reqsk_free
> > req->rsk_ops->destructor/tcp_v4_reqsk_destructor
> > kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1));
> >
> > Calling kmalloc() between the double kfree() can lead to use-after-free, so
> > this patch fixes it by setting NULL to inet_opt before sock_put().
> >
> > As a side note, this kind of issue does not happen for IPv6. This is
> > because tcp_v6_syn_recv_sock() clones both ipv6_opt and pktopts which
> > correspond to ireq_opt in IPv4.
> >
> > Fixes: 01770a166165 ("tcp: fix race condition when creating child sockets from syncookies")
> > CC: Ricardo Dias <rdias@xxxxxxxxxxxxxxx>
> > Signed-off-by: Kuniyuki Iwashima <kuniyu@xxxxxxxxxxxx>
> > Reviewed-by: Benjamin Herrenschmidt <benh@xxxxxxxxxx>
>
> Ricardo, Eric, any reason this was written this way?

Well, I guess that was a plain bug.

IPv4 options are not used often I think.

Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>