Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp372726pxb; Wed, 20 Jan 2021 09:00:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJz6q93ooMvEQHFX33QFWpeHgFgFBBtuDFPqZUNNkkEfEu97bhvgefYSfJPho1hwR6fGLDXf X-Received: by 2002:a17:906:5585:: with SMTP id y5mr2370666ejp.486.1611162030841; Wed, 20 Jan 2021 09:00:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611162030; cv=none; d=google.com; s=arc-20160816; b=m/wmNvKJm3hk7ab8F1P30FketbnzSmXzW2D16TcVrgyCZb/qiH03oolvcHdotsNNzj kOQY6ygIGKLHCt5EUFbAa3o6lRw8dW7+9UiWGihl2xxoVn8no4IlhFnpvna+O2ugFp+p dzjS1QONAlgNIbQ1tmbprd9UKKxfWoXsDPI+fxK2YROBEqUZ57LDLSemaMFribEacoac 6TFNDIeczSylCwOHFVYeUIv4Pso6fNiGN4B9IT0bdx9/tBML5WetdcGl15xAlnmwgo7x A4b0EoZtgTlVXZUrZF09fklYj7QBcexUPtXSvKcAX60TxdY4kxn0PWX/FBYGUTWVZRyi udyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=g2XiqLe5O8pDZWjw5dzsgeC9ienb2tOaAsrfuyk2TPI=; b=A0kpuoCljALZ4wLhOHeZVYpZh41p1qoWlmfAw67PcRyIFtwtcPhgKR6wtJ8GUClyy4 JqyzSTdaGr6vstEWIjwBwkwi2unSfm9TAYuZIMWVG9gGc20LQK0EM7lCJ7As48dccAWO HGVmOw6qZZJRLZ6HYAwTbF4oIaYUVpQlW1FabC+YTa0l6RdoDSL53PJNgfwcsM/wc6am Gdc4RDT8CD25iWUpNqOFiXDMUM+kP/asJBYOeQwOsguuaX75UIuWq7zSejKgEvD+pgyd ZsJUAP5A0RE0WM4Ek/HIvOkXOWe8pS1n90YLnlmjSXXUr6AmAJKo9BLZBDnnTIuKKw48 sZ8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="V/URu8aw"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t16si1056014edr.4.2021.01.20.09.00.06; Wed, 20 Jan 2021 09:00:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="V/URu8aw"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729676AbhATQ7F (ORCPT + 99 others); Wed, 20 Jan 2021 11:59:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:57048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391595AbhATQ6N (ORCPT ); Wed, 20 Jan 2021 11:58:13 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id F299123358; Wed, 20 Jan 2021 16:57:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611161852; bh=u+6rcQmeDhL1NAyEhUPgZGBH+HZF9sOcBSQlmtfRPWo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=V/URu8awx9yzmkYvPFKklqQ7tQj7q4CDNsT/zOBhHyo6NihSBIXoSn+SFVyAspNXK /+7qzh9zdlTdfaiq9ygDbIZlHhwW4XXv3MCvNludWOn344dSVniW6NV91pUu4Y4aBI /hnjEMjW55gFaBl7vR9+3eGUGl3PRxsHiPI5DnHpIQw5KM4atP4q8LPpkGVq2e32Lf OH0xfDWI+tLIHpxzH8XeLvs8dgc4hCtfN/JKSO8SN3XeCiiWTZJOU2rjuIz6FufXvs 2xhnzTnYqcq43LRPa/QfebRKk6Ug738GH0MPhsalf4ygTb/S9VEGL8c0NWnnRvw6JM TBpWByWIkQArA== Date: Wed, 20 Jan 2021 08:57:30 -0800 From: Jakub Kicinski To: Eric Dumazet , Kuniyuki Iwashima Cc: Kuniyuki Iwashima , "David S . Miller" , Hideaki YOSHIFUJI , netdev , LKML , Benjamin Herrenschmidt , Ricardo Dias Subject: Re: [PATCH net] tcp: Fix potential use-after-free due to double kfree(). Message-ID: <20210120085730.54e74b59@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20210118055920.82516-1-kuniyu@amazon.co.jp> <20210119171745.6840e3a5@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Jan 2021 14:07:35 +0100 Eric Dumazet wrote: > On Wed, Jan 20, 2021 at 2:17 AM Jakub Kicinski 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 > > > Signed-off-by: Kuniyuki Iwashima > > > Reviewed-by: Benjamin Herrenschmidt > > > > 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. I see. > Reviewed-by: Eric Dumazet Applied, thank you!