From patchwork Fri Mar 21 11:52:52 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 14025314 X-Patchwork-Delegate: kuba@kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78EA322332C for ; Fri, 21 Mar 2025 11:54:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558042; cv=none; b=lwtQF86FVrCBu0AdwplRLcxw4J8HLXVGiqiRQ/ROlBeQGvE/pgPeOubYBrlA/VeHSF2r/VeszXHBuioGKQiExh/K2MHDn0uOMpZzCn1NEvUlt/sBIwM2ege+fb5nRqpm8ikEZOWmty6c6e6P/2F5xDBGkyCiUiz4TOVzG3uQo1I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558042; c=relaxed/simple; bh=fFEBmNXZAj97owxosfDuZ1PvhJ86k5AAufbjCfYBHdk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BSKn+GWMaU2riYm/lt0DKkWgBgp81P/LJIoBLL4OXANPW1GQNoHL4x6PftvP3Q28sGQiAf/YQtbs+qwzJBVHZkl+B8cJbIg72yQq0O/J+H8YqhOrKDla5svFAV82IBsVVH3OpJh0VwoCTD1Qk6w1SNAOWjN/cDKteXjXWv9GtvA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=WMLWaBqk; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WMLWaBqk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742558039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rTBqSO1E5sbU6a5eCrmvivcUTinpdVFuKl5JRaK8lS0=; b=WMLWaBqkvq6kTymC9K58hypxmkWxcjHTeWFJfytmv9TFZ7AkSSS6jYpJCSYg9ny42CFUFz oBzSd8q5LN0/xU9rg2rFbgVG1zNrrPd9xxu7CIlUug8OkDmg7SabuafPZ6s9RbRk/yqMrS ZUcdStIdwgV8kjzHrla4afssTEI4f8I= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-508-11ni0tqsNz2qqDTXToT1Vg-1; Fri, 21 Mar 2025 07:53:56 -0400 X-MC-Unique: 11ni0tqsNz2qqDTXToT1Vg-1 X-Mimecast-MFC-AGG-ID: 11ni0tqsNz2qqDTXToT1Vg_1742558034 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B825F196D2D0; Fri, 21 Mar 2025 11:53:54 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.45.225.31]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6986A180175B; Fri, 21 Mar 2025 11:53:51 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Willem de Bruijn , David Ahern , Nathan Chancellor Subject: [PATCH net-next v2 1/5] udp_tunnel: properly deal with xfrm gro encap. Date: Fri, 21 Mar 2025 12:52:52 +0100 Message-ID: In-Reply-To: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Patchwork-Delegate: kuba@kernel.org The blamed commit below does not take in account that xfrm can enable GRO over UDP encapsulation without going through setup_udp_tunnel_sock(). At deletion time such socket will still go through udp_tunnel_cleanup_gro(), and the failed GRO type lookup will trigger the reported warning. Add the GRO accounting for XFRM tunnel when GRO is enabled, and adjust the known gro types accordingly. Note that we can't use setup_udp_tunnel_sock() here, as the xfrm tunnel setup can be "incremental" - e.g. the encapsulation is created first and GRO is enabled later. Also we can not allow GRO sk lookup optimization for XFRM tunnels, as the socket could match the selection criteria at enable time, and later on the user-space could disconnect/bind it breaking such criteria. Reported-by: syzbot+8c469a2260132cd095c1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8c469a2260132cd095c1 Fixes: 311b36574ceac ("udp_tunnel: use static call for GRO hooks when possible") Signed-off-by: Paolo Abeni --- v1 -> v2: - do proper account for xfrm, retain the warning --- net/ipv4/udp.c | 5 +++++ net/ipv4/udp_offload.c | 4 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index db606f7e41638..79efbf465fb04 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -2903,10 +2903,15 @@ static void set_xfrm_gro_udp_encap_rcv(__u16 encap_type, unsigned short family, { #ifdef CONFIG_XFRM if (udp_test_bit(GRO_ENABLED, sk) && encap_type == UDP_ENCAP_ESPINUDP) { + bool old_enabled = !!udp_sk(sk)->gro_receive; + if (family == AF_INET) WRITE_ONCE(udp_sk(sk)->gro_receive, xfrm4_gro_udp_encap_rcv); else if (IS_ENABLED(CONFIG_IPV6) && family == AF_INET6) WRITE_ONCE(udp_sk(sk)->gro_receive, ipv6_stub->xfrm6_gro_udp_encap_rcv); + + if (!old_enabled && udp_sk(sk)->gro_receive) + udp_tunnel_update_gro_rcv(sk, true); } #endif } diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 088aa8cb8ac0c..02365b818f1af 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -37,9 +37,11 @@ struct udp_tunnel_type_entry { refcount_t count; }; +/* vxlan, fou and xfrm have 2 different gro_receive hooks each */ #define UDP_MAX_TUNNEL_TYPES (IS_ENABLED(CONFIG_GENEVE) + \ IS_ENABLED(CONFIG_VXLAN) * 2 + \ - IS_ENABLED(CONFIG_NET_FOU) * 2) + IS_ENABLED(CONFIG_NET_FOU) * 2 + \ + IS_ENABLED(CONFIG_XFRM) * 2) DEFINE_STATIC_CALL(udp_tunnel_gro_rcv, dummy_gro_rcv); static DEFINE_STATIC_KEY_FALSE(udp_tunnel_static_call); From patchwork Fri Mar 21 11:52:53 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 14025315 X-Patchwork-Delegate: kuba@kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2556122332C for ; Fri, 21 Mar 2025 11:54:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558047; cv=none; b=eNNQDQ0zIL95rGYBoWdNjCywP+Y4NcUxbYXwcyl5DXMZta/c8e+vf0Dex/TUVNqh2/hEx6+MgrpXm45MVmz9DBAXmkwBxxXLUf7SdE92KxZtaFFsd3OPTQo62EjQ4sZrx/Zj4EHjR97LLaUZ0S1wqZ6fG638mZszRhV+ojknhQY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558047; c=relaxed/simple; bh=fUyfcu7JQF5lDF+GGfk17XwbuAbPq/fE8E1QzqK7GBw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=J+jsk6tSAB+xwX8ZtOm/nv8h798CN0kbTHdV49P7P0cFWc/Y0zBRM36Sz1957AW/VNyL8EkNXSQEbeLMO4R0f316uC5b6eu502/YgvXPULKGcA4fYamH8Uvc+xA3rweOdJ3h+aJ913kDhaIMIhE4n8RRVm5DlTw9wMy0+br6zuE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=RnNInn+7; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RnNInn+7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742558045; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ax0yzd92ySS/YqU6nPgZh27nficwYyRDz3W/JAP2gsg=; b=RnNInn+7tUclMRNV4sTviTvSQoRnc65DV+HxTFSjUXm+Mcw2204x9wsiz70scZA53pVglG ZQr4quJXfrdNavbW7QptJvvL3tpScm+BC3cJNVKAtIXuOHU9sN0nmwCpQcoAT/TQnkxvyq q0Pf2JDsqosrsjdwu/wpGUd5EYWx6zQ= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-369-M4e8-ZDTNn6KNXUrvOj8Jw-1; Fri, 21 Mar 2025 07:53:59 -0400 X-MC-Unique: M4e8-ZDTNn6KNXUrvOj8Jw-1 X-Mimecast-MFC-AGG-ID: M4e8-ZDTNn6KNXUrvOj8Jw_1742558038 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 668A619560B1; Fri, 21 Mar 2025 11:53:58 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.45.225.31]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 363C2180175A; Fri, 21 Mar 2025 11:53:54 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Willem de Bruijn , David Ahern , Nathan Chancellor Subject: [PATCH net-next v2 2/5] udp_tunnel: fix compile warning Date: Fri, 21 Mar 2025 12:52:53 +0100 Message-ID: <5c4df4171225ab664c748da190c6f2c2f662c48b.1742557254.git.pabeni@redhat.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Patchwork-Delegate: kuba@kernel.org Nathan reported that the compiler is not happy to use a zero size udp_tunnel_gro_types array: net/ipv4/udp_offload.c:130:8: warning: array index 0 is past the end of the array (that has type 'struct udp_tunnel_type_entry[0]') [-Warray-bounds] 130 | udp_tunnel_gro_types[0].gro_receive); | ^ ~ include/linux/static_call.h:154:42: note: expanded from macro 'static_call_update' 154 | typeof(&STATIC_CALL_TRAMP(name)) __F = (func); \ | ^~~~ net/ipv4/udp_offload.c:47:1: note: array 'udp_tunnel_gro_types' declared here 47 | static struct udp_tunnel_type_entry udp_tunnel_gro_types[UDP_MAX_TUNNEL_TYPES]; | ^ 1 warning generated. In such (unusual) configuration we should skip entirely the static call optimization accounting. Reported-by: syzbot+8c469a2260132cd095c1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/cover.1741718157.git.pabeni@redhat.com/T/#m6e309a49f04330de81a618c3c166368252ba42e4 Fixes: 311b36574ceac ("udp_tunnel: use static call for GRO hooks when possible") Signed-off-by: Paolo Abeni --- net/ipv4/udp_offload.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 02365b818f1af..fd2b8e3830beb 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -83,7 +83,7 @@ void udp_tunnel_update_gro_rcv(struct sock *sk, bool add) struct udp_sock *up = udp_sk(sk); int i, old_gro_type_nr; - if (!up->gro_receive) + if (!UDP_MAX_TUNNEL_TYPES || !up->gro_receive) return; mutex_lock(&udp_tunnel_gro_type_lock); From patchwork Fri Mar 21 11:52:54 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 14025316 X-Patchwork-Delegate: kuba@kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC08E22332C for ; Fri, 21 Mar 2025 11:54:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558051; cv=none; b=UES+ictJh9OwBoTTZk56+eS/ADO1nprp6a5xGYbFdImN7XcMqy75jYogyjKW/A9+y7T+WbWeLjlApM/e8bLdma1U4Y5iPZip3eI8ZIxcBd37eRVIIjMWWx3587g5C8JtZwWY6GvHfBFIRcO0VTzxyT+u+/cM3i+gBUAh8hgk5LU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558051; c=relaxed/simple; bh=6yFycll2LhqQPNwBiehC3WfdCYrOTpshzY4S8MdN2rM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=phvERBM4sXdz/5z/QcYUFCuute+wjocLQ2syZZtx6SKcSLWnAg6u8uScPSr+krMcf0pP7BsqEcPZOR9rhinPWFvO2vSd0aYO5kBv68KiCYpR/s9f/0yqgu41v8Db2U5xgETYc3waT6wSc70uTkxCqeg6AdQyIgvde3C8+c8IpRI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XsV6DqdF; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XsV6DqdF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742558048; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RnteUWt9wyYhbRiJ1qeHsqWxQRBKMCdaAPqGdqoj5gE=; b=XsV6DqdFjnUBPomEnpPU5VGzMXO4qwQQvJwBYC8baxifnb4SszNfcqkbWakQwH6Vxx2YL5 EQ94mc0exw5aZ56VDCfAz1jPBMtZNt7IAz+cvPPZLE7VnsmGZilHkdVNi2TMk3equaKP/k cxPpp5Y4Xia8iHLcFIZkYdUR3WSv8Mw= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-39-A5g0SpEvMcGwbn0-vUe_gQ-1; Fri, 21 Mar 2025 07:54:03 -0400 X-MC-Unique: A5g0SpEvMcGwbn0-vUe_gQ-1 X-Mimecast-MFC-AGG-ID: A5g0SpEvMcGwbn0-vUe_gQ_1742558042 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 033C01933B48; Fri, 21 Mar 2025 11:54:02 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.45.225.31]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id EDF91180175A; Fri, 21 Mar 2025 11:53:58 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Willem de Bruijn , David Ahern , Nathan Chancellor Subject: [PATCH net-next v2 3/5] udp_tunnel: fix UaF in GRO accounting Date: Fri, 21 Mar 2025 12:52:54 +0100 Message-ID: <70a8c5bdf58ed1937e2f3edbefb37c55cfe6ebc1.1742557254.git.pabeni@redhat.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Patchwork-Delegate: kuba@kernel.org Siyzkaller reported a race in UDP tunnel GRO accounting, leading to UaF: BUG: KASAN: slab-use-after-free in udp_tunnel_update_gro_lookup+0x23c/0x2c0 net/ipv4/udp_offload.c:65 Read of size 8 at addr ffff88801235ebe8 by task syz.2.655/7921 CPU: 1 UID: 0 PID: 7921 Comm: syz.2.655 Not tainted 6.14.0-rc6-syzkaller-01313-g23c9ff659140 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x16e/0x5b0 mm/kasan/report.c:521 kasan_report+0x143/0x180 mm/kasan/report.c:634 udp_tunnel_update_gro_lookup+0x23c/0x2c0 net/ipv4/udp_offload.c:65 sk_common_release+0x71/0x2e0 net/core/sock.c:3896 inet_release+0x17d/0x200 net/ipv4/af_inet.c:435 __sock_release net/socket.c:647 [inline] sock_release+0x82/0x150 net/socket.c:675 sock_free drivers/net/wireguard/socket.c:339 [inline] wg_socket_reinit+0x215/0x380 drivers/net/wireguard/socket.c:435 wg_stop+0x59f/0x600 drivers/net/wireguard/device.c:133 __dev_close_many+0x3a6/0x700 net/core/dev.c:1717 dev_close_many+0x24e/0x4c0 net/core/dev.c:1742 unregister_netdevice_many_notify+0x629/0x24f0 net/core/dev.c:11923 rtnl_delete_link net/core/rtnetlink.c:3512 [inline] rtnl_dellink+0x526/0x8c0 net/core/rtnetlink.c:3554 rtnetlink_rcv_msg+0x791/0xcf0 net/core/rtnetlink.c:6945 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f35ab38d169 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f35ac28f038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f35ab5a6160 RCX: 00007f35ab38d169 RDX: 0000000000000000 RSI: 0000400000000000 RDI: 0000000000000004 RBP: 00007f35ab40e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000001 R14: 00007f35ab5a6160 R15: 00007ffdddd781b8 Allocated by task 7770: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4115 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x1d9/0x380 mm/slub.c:4171 sk_prot_alloc+0x58/0x210 net/core/sock.c:2190 sk_alloc+0x3e/0x370 net/core/sock.c:2249 inet_create+0x648/0xea0 net/ipv4/af_inet.c:326 __sock_create+0x4c0/0xa30 net/socket.c:1539 sock_create net/socket.c:1597 [inline] __sys_socket_create net/socket.c:1634 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1681 __do_sys_socket net/socket.c:1695 [inline] __se_sys_socket net/socket.c:1693 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1693 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 7768: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4609 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4711 sk_prot_free net/core/sock.c:2230 [inline] __sk_destruct+0x4fd/0x690 net/core/sock.c:2327 inet_release+0x17d/0x200 net/ipv4/af_inet.c:435 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1389 __fput+0x3e9/0x9f0 fs/file_table.c:464 task_work_run+0x24f/0x310 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x13f/0x340 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88801235e4c0 which belongs to the cache UDP of size 1856 The buggy address is located 1832 bytes inside of freed 1856-byte region [ffff88801235e4c0, ffff88801235ec00) At disposal time, to avoid unconditionally acquiring a spin lock, UDP tunnel sockets are conditionally removed from the known tunnels list only if the socket is actually present in such a list. Such check happens outside the socket lock scope: the current CPU could observe an uninitialized list entry even if the tunnel has been actually registered by a different core. Address the issue moving the blamed check under the relevant list spin lock. Reported-by: syzbot+1fb3291cc1beeb3c315a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1fb3291cc1beeb3c315a Fixes: 8d4880db37835 ("udp_tunnel: create a fastpath GRO lookup.") Signed-off-by: Paolo Abeni Reviewed-by: Willem de Bruijn --- include/net/udp_tunnel.h | 4 ---- net/ipv4/udp_offload.c | 3 ++- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h index a7b230867eb14..13b54e6856414 100644 --- a/include/net/udp_tunnel.h +++ b/include/net/udp_tunnel.h @@ -214,14 +214,10 @@ static inline void udp_tunnel_update_gro_rcv(struct sock *sk, bool add) {} static inline void udp_tunnel_cleanup_gro(struct sock *sk) { - struct udp_sock *up = udp_sk(sk); struct net *net = sock_net(sk); udp_tunnel_update_gro_rcv(sk, false); - if (!up->tunnel_list.pprev) - return; - udp_tunnel_update_gro_lookup(net, sk, false); } diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index fd2b8e3830beb..b124355a36aee 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -57,10 +57,11 @@ void udp_tunnel_update_gro_lookup(struct net *net, struct sock *sk, bool add) struct udp_tunnel_gro *udp_tunnel_gro; spin_lock(&udp_tunnel_gro_lock); + udp_tunnel_gro = &net->ipv4.udp_tunnel_gro[is_ipv6]; if (add) hlist_add_head(&up->tunnel_list, &udp_tunnel_gro->list); - else + else if (up->tunnel_list.pprev) hlist_del_init(&up->tunnel_list); if (udp_tunnel_gro->list.first && From patchwork Fri Mar 21 11:52:55 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 14025317 X-Patchwork-Delegate: kuba@kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40DCC2253A5 for ; Fri, 21 Mar 2025 11:54:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558053; cv=none; b=HFEeYFRbKnaBF3Nf2Jp8wAFe8wi8tVOTcAM8bNPVRjOjmFn2iGV3wG6BuyOR/pCsxo2LpHFMwQwpgtUG7PoKmgEWsNrWI4FesnDRmYN71H6OouPdmFQQa4IFXeW7TtCerkzJgA2P7SpP9bkdOBrlpyrS/vom8YQUN//L0E+aA8w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558053; c=relaxed/simple; bh=U2JOwp6DtMRFNez4QN0EOTJDgdqZLD26FV2M2V2Rcv4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PsHfSUMkttfaBcVP6h+qTdZ9SvAlhSOGJTrK3QTDXAlaehhp3UHE6+V+BRb8bftX8aPL+0R+YghZXbZfiRQUHxH0Xl/9mT9yib+GMJGUWG2mKrpTZ/QO4TpNDKf6ZkblXdvvG8gpga25BaszrDXxJYkd+8l411iv9FY8DP4TCOM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Q4o7oInH; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Q4o7oInH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742558051; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eHBUmN4exdzS6O8/31aKZhVk/RfP+2gZKpXatuGkios=; b=Q4o7oInHJWnmW3lvQ8rTe9EP/tawddJOZDVp2Cofplc62M/O7F1swM+79kpDnbiD3CyWWW gxqx92gvUmJqYQFZg5DiZSfh7aA4VLTHBnUqKfr7oa5W1VpNFRV5ptrFfvL/h16lMOuV9t i6ofz3xsdXS5bd6FHuExqUKyWWakaA0= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-600-FRbyv0jtPn2r4BP-Tg-goQ-1; Fri, 21 Mar 2025 07:54:07 -0400 X-MC-Unique: FRbyv0jtPn2r4BP-Tg-goQ-1 X-Mimecast-MFC-AGG-ID: FRbyv0jtPn2r4BP-Tg-goQ_1742558045 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A866F196B356; Fri, 21 Mar 2025 11:54:05 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.45.225.31]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 884CA1801762; Fri, 21 Mar 2025 11:54:02 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Willem de Bruijn , David Ahern , Nathan Chancellor Subject: [PATCH net-next v2 4/5] udp_tunnel: avoid inconsistent local variables usage Date: Fri, 21 Mar 2025 12:52:55 +0100 Message-ID: <0d33ffb4f809093d56f3ebdffd599050136f316a.1742557254.git.pabeni@redhat.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Patchwork-Delegate: kuba@kernel.org In setup_udp_tunnel_sock() 'sk' and 'sock->sk' are alias. The code I introduced there uses alternatively both variables, for no good reasons. Stick to 'sk' usage, to be consistent with the prior code. Signed-off-by: Paolo Abeni Reviewed-by: Willem de Bruijn --- net/ipv4/udp_tunnel_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c index c49fceea83139..aa9016619c25a 100644 --- a/net/ipv4/udp_tunnel_core.c +++ b/net/ipv4/udp_tunnel_core.c @@ -90,10 +90,10 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock, udp_tunnel_encap_enable(sk); - udp_tunnel_update_gro_rcv(sock->sk, true); + udp_tunnel_update_gro_rcv(sk, true); - if (!sk->sk_dport && !sk->sk_bound_dev_if && sk_saddr_any(sock->sk)) - udp_tunnel_update_gro_lookup(net, sock->sk, true); + if (!sk->sk_dport && !sk->sk_bound_dev_if && sk_saddr_any(sk)) + udp_tunnel_update_gro_lookup(net, sk, true); } EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock); From patchwork Fri Mar 21 11:52:56 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 14025318 X-Patchwork-Delegate: kuba@kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A50712236F6 for ; Fri, 21 Mar 2025 11:54:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558060; cv=none; b=VlXvPZVuXXDQNTtAKKoKxfFpiwtor2QjE+BMsXac/uOSDdVZl9sIGKTjnPk/zwskv9b9YmfwHZkGe/ZrEWoROaX49QRVPjE7uI3ob73KCd/6DgHMQxOalgpD09KziiXpE8fv0auklGGbt4WgQg08R3q1anQhiIrXMll6cB7nwJ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742558060; c=relaxed/simple; bh=pdywwyIayKogf87oN//uzTnfLtqQGG6KsOSsoVWgr+U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ADipmr+OFQTCrHGfle1lUFNt+FGu1+MAvjc1peRuW8ZI1dWPRFGxy8WZEz/urlD5+s1vtiNLgT9kPcZ2Ns/xb5rEjMO91dmnpOPglJERzQTwtCwikSRORIByTIYS59uxizIR6vfdEXWpz0s7nPf12Hp4IQgmAEzVz1i9H8umwZs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TOh72Shn; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TOh72Shn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742558057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GbletQxslZ4D1Q6oiKeS4bSsCigDnk9bRZm0p5ktGSk=; b=TOh72ShnG67PqNZgYtId4L+wd+pXLq8KshcTL5hpBZsLXRbCdWzBh06+IHocX4QRlX1bYM 5JNs8DOOfJVkj9jY/OtuuJX8iYHu9jPMiv/aZqD0TResb1D8yEb433kAoz69EGipxrn1qw Q7ck+b+DrN9TyHVr+p1tH4m1Sw2ymXw= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-439-h1ql678FNASf6wjYfLBhKg-1; Fri, 21 Mar 2025 07:54:10 -0400 X-MC-Unique: h1ql678FNASf6wjYfLBhKg-1 X-Mimecast-MFC-AGG-ID: h1ql678FNASf6wjYfLBhKg_1742558049 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 753AC196D2CC; Fri, 21 Mar 2025 11:54:09 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.45.225.31]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 44D95180175A; Fri, 21 Mar 2025 11:54:05 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Willem de Bruijn , David Ahern , Nathan Chancellor Subject: [PATCH net-next v2 5/5] udp_tunnel: prevent GRO lookup optimization for user-space sockets Date: Fri, 21 Mar 2025 12:52:56 +0100 Message-ID: In-Reply-To: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Patchwork-Delegate: kuba@kernel.org UDP tunnel sockets owned by the kernel are never disconnected/rebound after setup_udp_tunnel_sock(), but sockets owned by the user-space could go through such changes after being matching the criteria to enable the GRO lookup optimization, breaking them. Explicitly prevent user-space owned sockets from leveraging such optimization. Signed-off-by: Paolo Abeni Reviewed-by: Willem de Bruijn --- net/ipv4/udp_tunnel_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c index aa9016619c25a..2326548997d3f 100644 --- a/net/ipv4/udp_tunnel_core.c +++ b/net/ipv4/udp_tunnel_core.c @@ -92,7 +92,8 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock, udp_tunnel_update_gro_rcv(sk, true); - if (!sk->sk_dport && !sk->sk_bound_dev_if && sk_saddr_any(sk)) + if (!sk->sk_dport && !sk->sk_bound_dev_if && sk_saddr_any(sk) && + sk->sk_kern_sock) udp_tunnel_update_gro_lookup(net, sk, true); } EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock);