From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0B08C0015E for ; Wed, 9 Aug 2023 15:56:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231974AbjHIP42 (ORCPT ); Wed, 9 Aug 2023 11:56:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231299AbjHIP40 (ORCPT ); Wed, 9 Aug 2023 11:56:26 -0400 Received: from smtp-fw-52005.amazon.com (smtp-fw-52005.amazon.com [52.119.213.156]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4402D2698; Wed, 9 Aug 2023 08:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1691596567; x=1723132567; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SsgNs8WP7Va7/HPmzzpveitPd422Cl33ClfKs6muCY8=; b=DHFk60Fga6jL5POkjcp2KhSALBJofqV3R2ze8tdgMKXbCLLsRwLEsdGh OFEQyS7RqIhFeEWNAq3m54u3wJ/2ck1dEw3KjPnJwLEmLnCP4GUlJwAz5 Zg6F17GaIglCDcCIXtbDTDhB3XYCSBsNeR3YO577gbFUCSAWNJFX/z5Br s=; X-IronPort-AV: E=Sophos;i="6.01,159,1684800000"; d="scan'208";a="597758339" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-iad-1d-m6i4x-153b24bc.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-52005.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 15:56:04 +0000 Received: from EX19MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1d-m6i4x-153b24bc.us-east-1.amazon.com (Postfix) with ESMTPS id 400C7C1540; Wed, 9 Aug 2023 15:55:59 +0000 (UTC) Received: from EX19D004ANA001.ant.amazon.com (10.37.240.138) by EX19MTAUWB001.ant.amazon.com (10.250.64.248) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Wed, 9 Aug 2023 15:55:50 +0000 Received: from 88665a182662.ant.amazon.com (10.106.100.32) by EX19D004ANA001.ant.amazon.com (10.37.240.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.30; Wed, 9 Aug 2023 15:55:46 +0000 From: Kuniyuki Iwashima To: CC: , , , , , , , , , , , Subject: Re: [PATCH bpf-next] net: Fix slab-out-of-bounds in inet[6]_steal_sock Date: Wed, 9 Aug 2023 08:55:38 -0700 Message-ID: <20230809155538.67000-1-kuniyu@amazon.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.106.100.32] X-ClientProxiedBy: EX19D036UWB004.ant.amazon.com (10.13.139.170) To EX19D004ANA001.ant.amazon.com (10.37.240.138) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Lorenz Bauer Date: Wed, 9 Aug 2023 16:08:31 +0100 > On Wed, Aug 9, 2023 at 3:39 PM Martin KaFai Lau wrote: > > > > On 8/9/23 1:33 AM, Lorenz Bauer wrote: > > > Kumar reported a KASAN splat in tcp_v6_rcv: > > > > > > bash-5.2# ./test_progs -t btf_skc_cls_ingress > > > ... > > > [ 51.810085] BUG: KASAN: slab-out-of-bounds in tcp_v6_rcv+0x2d7d/0x3440 > > > [ 51.810458] Read of size 2 at addr ffff8881053f038c by task test_progs/226 > > > > > > The problem is that inet[6]_steal_sock accesses sk->sk_protocol without > > > accounting for request sockets. I added the check to ensure that we only > > > every try to perform a reuseport lookup on a supported socket. > > > > > > It turns out that this isn't necessary at all. struct sock_common contains > > > a skc_reuseport flag which indicates whether a socket is part of a > > > > Does it go back to the earlier discussion > > (https://lore.kernel.org/bpf/7188429a-c380-14c8-57bb-9d05d3ba4e5e@linux.dev/) > > that the sk->sk_reuseport is 1 from sk_clone for TCP_ESTABLISHED? It works > > because there is sk->sk_reuseport"_cb" check going deeper into > > reuseport_select_sock() but there is an extra inet6_ehashfn for all TCP_ESTABLISHED. > > Sigh, I'd forgotten about this... > > For the TPROXY TCP replacement use case we sk_assign the SYN to the > listener, which creates the reqsk. We can let follow up packets pass > without sk_assign since they will match the reqsk and convert to a > fullsock via the usual route. At least that is what the test does. I'm > not even sure what it means to redirect a random packet into an > established TCP socket TBH. It'd probably be dropped? > > For UDP, I'm not sure whether we even get into this situation? Doesn't > seem like UDP sockets are cloned from each other, so we also shouldn't > end up with a reuseport flag set erroneously. > > Things we could do if necessary: > 1. Reset the flag in inet_csk_clone_lock like we do for SOCK_RCU_FREE I think we can't do this as sk_reuseport is inherited to twsk and used in inet_bind_conflict(). > 2. Duplicate the cb check into inet[6]_steal_sock or 3. Add sk_fullsock() test ?