From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com [74.125.224.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 416EC2F8EA5 for ; Tue, 25 Aug 2026 04:56:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787633805; cv=none; b=vF2NhyQXH+WX3ynBMQt2WxeoG7Fr24C5735g/+wf454WZbLyfqbBvkApTLdnMc4pdTLLY9w3GzDj6+GSdUwKfsdKbPLlnv2joaK7wZdf1cjR3OCTdWdwa0iTOw31XXgb5TYc0KRKONsr+5s13QYO2Y+QjNwP0T0VT/DEFui421k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787633805; c=relaxed/simple; bh=xh8zMmJjjGXC6wtiuYUFUCvEzj2uoVqq+mklBD7siOY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KkdFnFYr7lZj0uJk2tqpB6oCGXrWsyCylQvME+6D7Fxxydt25vTKstFy4pN8TTYYXncaFL1/P39KLu8loLjfy9KGI42Mk6hM/gT9m6CwqDFoPEg4P1dd16gzpxt2AZj1j4i+YbP2k9zAs1q90KgExtxg2aXXBk3+oPTWkCRGIhw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=V549B50A; arc=none smtp.client-ip=74.125.224.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V549B50A" Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-66825847b2cso4587158d50.3 for ; Mon, 24 Aug 2026 21:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787633803; x=1788238603; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=xh8zMmJjjGXC6wtiuYUFUCvEzj2uoVqq+mklBD7siOY=; b=V549B50AskZb/pSEw2NWzpGu0EPN7QJCl3ht+YXroBFnoAAKKO0jmaWcEv9i2neCiq D7kIv2XX23XLEJ8nq4tj88sGdJfKSsUSKtrVybrQqfVyhaU8CMAIxUN9iiPvR9r+Z0U0 U+H1BuOZkW1cLCEJf3JxK+p173H3rH5s4GyJHl7Z1Xsb19vevNqL6xq3nN8MmWBTBtM7 qucMchabZCLuoP/3a5XaBVGvYHArT1SRuW8mqVx/bFiO7qZ3yX+ZH5nj+cpt8BhAPnZl ftnnSW2LJbObrGN0CqSqHBcU6ARP9yIa/OZ4SCWRvYpcSJtX2VYyQeplb4eFB+VeYmuf WjHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787633803; x=1788238603; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=xh8zMmJjjGXC6wtiuYUFUCvEzj2uoVqq+mklBD7siOY=; b=iOyMa37RaKV7UedxIO+yp1QVwiy0hQ1WK+8ormkZTBWb46xUCw4eQXOGdVfWqLcOGR IL6DICegJEAkg+Qse0BRcjtg9VWNBJndsXJSeQE1SWUVmDitCsG1HkctoeKKox45SjvC UKVWt5ydDtN0UcO8rVbYJWHUXCS/8ZZ16uqxb03IfaH/MzV8sKWwbegW8ZRoFAYV/T7p YnL+/dMXiF6v9eUkGFtyIESVU9ND/K0/aedQRpbrtv/w2fHb36UbdoFMk0eUteoCQY8c 2Fu6zreJN2anzDLTeFXdJAfzYwOO+6DPz5f6krzD+k2ihMKMeHj1EQJN+hR6tWPiydYb RmAw== X-Forwarded-Encrypted: i=1; AHgh+RpWlItn6GNSpaBdg/6ufVAiIeXZHRtlGMCFqiqpHFFy58HEcPuPqTf2qTRGwbo/F8iwGknnn9QXUGHelMo=@vger.kernel.org X-Gm-Message-State: AFuF++nZWOjWAFrgmWPoWW3s46gQTL+naDSiK5f/ENTr7CoZ2OckB8Zk CMoQ1zp8q/GfhixtDClJpyfoxIHX4T1f8okmEMUsE/wGuGWjuyv4DnxN X-Gm-Gg: AR+sD13ctiznc+G/wDm9iYn2JBghD8F7S0sbtD86+wqIy+DndfaxF4KO/Cdq5u8zbhL QuOJ5gi43RbvpNlSNXfNBm4W1UI8qpW5VGO7F3RCJn/g6Q5YC6g/+ziBnK4uyF8xi1tk66bMZzr Yu4laF0jChEsSp+YVx24K2LIl4EOGqr3FkZGf4jjwoDto064sHT2+n3wxH3uu+Pq1YBYqulyaX2 CNO/QMe7BH26aStBeuHPjflDdO5dDfNAUBSCJiCaZdJgSX1wV2J2cZhCeHsU6uBDiovW0PErCrZ NMzJDG/gjsza/Uji66R/ovhcyPbHQUKWyjv3zo1s3DqO/cMKue2jZJfXm8BMLYS+UNSufQHZmtE RdjGnRAP0EqXzYeaJgcZYsq1A25sbnPg5dUSFcDoSItY7MgyWb6X5RbCu3Y8VUsUtDD2zE4Uj6s oXfCgeZPJLGHOxgye2EmgSoPrN7vF6aP+aWxM+X6VLpWQ6eoLMjsxkHK501HSGsmKFvl0= X-Received: by 2002:a53:b3c3:0:b0:66c:486c:aa07 with SMTP id 956f58d0204a3-66cf21bd42amr5572435d50.35.1787633803283; Mon, 24 Aug 2026 21:56:43 -0700 (PDT) Received: from mac.lan ([136.55.173.105]) by smtp.gmail.com with ESMTPSA id 00721157ae682-84ca62f6799sm43525737b3.19.2026.08.24.21.56.42 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 24 Aug 2026 21:56:42 -0700 (PDT) From: "Cen Zhang (Microsoft)" To: horms@kernel.org Cc: AutonomousCodeSecurity@microsoft.com, andrew+netdev@lunn.ch, blbllhy@gmail.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, kys@microsoft.com, laforge@gnumonks.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, osmocom-net-gprs@lists.osmocom.org, pabeni@redhat.com, pablo@netfilter.org, tgopinath@linux.microsoft.com, xmei5@asu.edu Subject: Re: [PATCH net] gtp: fix NULL pointer dereference in gtp0_handle_echo_resp() Date: Tue, 25 Aug 2026 00:56:40 -0400 Message-ID: <20260825045640.39522-1-blbllhy@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260819124820.GR265046@horms.kernel.org> References: <20260819124820.GR265046@horms.kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, Aug 19, 2026 at 01:48:20PM +0100, Simon Horman wrote: > I don't believe that this is sufficient to address the problem described as > there is no synchronisation between the reader and writer of sk_created. > > I wonder if this might be addressed using smp_store_release/smp_load_acquire. Thanks. v2 uses smp_store_release()/smp_load_acquire() as suggested. While reviewing all sk_created access points, we also found a teardown race in gtp_encap_disable() and a missing RTNL lock in gtp_genl_send_echo_req(). These are addressed in a new patch 2/2. Regarding the Sashiko review: https://sashiko.dev/#/patchset/20260816035205.57966-1-blbllhy@gmail.com > Could a concurrent RX softirq checking gtp->sk_created without > smp_load_acquire() still observe it as true while gtp->sk0 > remains NULL? Addressed in v2 patch 1/2. > Does the error path in gtp_create_sockets() properly synchronize > with concurrent RX softirqs? Could this lead to a Use-After-Free? Independent pre-existing issue. > Could the KASAN null pointer dereference actually be caused by the > teardown path? Does this path need synchronization to wait for > concurrent softirqs before clearing the pointers? We reproduced this and addressed it with another teardown path issue in v2 patch 2/2. > Does modifying the RX SKB in place during an echo response corrupt > data for concurrent readers (tcpdump)? Independent pre-existing issue. Cen