From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 465A73D3D16 for ; Thu, 23 Jul 2026 09:20:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784798449; cv=none; b=VC4nsS/QuHZN7Swt6bTb3u2aOJ5sJifX++1xQzo5BouMap1kZtZUjniDUv7MO9V5K+SisM0H9NRe2VhFdunD/rW6FqCWPZqG/8jIJ3ZMmxvSwScVpnszraDvdSSZjs/P1FQKlSAQ93a+BEjqk7kqJ4U4eMcvMtaFRMAY3MTHYaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784798449; c=relaxed/simple; bh=LfJCPXrkCvU4eIADzu4kkxml+HubEsRZjw6OEOvo9zk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Hu8tTgHXoWq54gfprBV99PxDylgdYGm7klWqiC2e8m1epRo1Cz5DJFZ1h3KKLhB6uRIipac2HF32bYs70d9JNjsiO7hQMuo9AWX//rD4vL5CdBz1Lg+/LkFUJ2NkZvCO50YxyVORKfkLsKEc6AWBMw+0yStku3mnnCTFwTYIUa4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org; spf=none smtp.mailfrom=blackwall.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b=j/AcdTZR; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=blackwall.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b="j/AcdTZR" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4954aff6088so3331305e9.3 for ; Thu, 23 Jul 2026 02:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall.org; s=google; t=1784798444; x=1785403244; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=t1pcUHyEXTLP5ioaaGQiLm4UUcHFQIHxMWGMjnBYpmk=; b=j/AcdTZRK5BjXg2QeQMdGWZcbQ9qfofvPEtn2NqT4R1KdJXsvHwKf0PjL36oc1F4Y5 mwGTXel8t1AIDq4mJ1QpmZZ8bOjwp2wFgbensgl9/yAVXEfXrMgIBc43lbpTkZhg1tvH 003g9odPDiKOZz05JwSBUviYslftxqMYBvaXqZFjGc01hPDL1yFSkuvYoAnoZr+Jjd4B f2u2k5EMmjYdb8PyZuUK3RArzOkMr9bpsoc7CzklsRW2bmoXSaNlvwke9N2R4IrWXC8n eulZDNJakmR5d9sYH0EtryxNFf81xct8aVRQW0DGA4n5YP7fBgJKEV5k1L2x39PrcvRR Irww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784798444; x=1785403244; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=t1pcUHyEXTLP5ioaaGQiLm4UUcHFQIHxMWGMjnBYpmk=; b=Gtdo7/iwPVP5VXWsiqM5hWBDiXwPlqUHtjHAJPWZSdcmBHwM/TbXFtRgWDeOrBXl+d ArUiMeIXI16vJnIq6v4xaFi+uNuAfvO80cqwUAl8PaZkC+wHxWE+vbiMCa7A7WkGG4l+ I5zmHtqvN5/hC9xQQYi7CLwQWWiJlpb/DVtIxVZ/XcF0zCDhcW0Xivu3HnQZnAefRwvN e+NIEssAyStjbIjlouLl7l0zV8XfMQP9Ssq00F6nuyhiLVQKudHndU59cfIjEEd82pdD 7Z0TjTluuuKs8gqMVzfI0Z1wEMw+80PLqotzLYZspQsXsMUcn0WqrxB0I+82qBNwoP4B EOzA== X-Forwarded-Encrypted: i=1; AHgh+RqMmVeiuQZnOO+ZuqnLda8JN8JkeUT1bRS5yRyjRe2fqGw8YEzXn50umvNOxRxKh8NggOSfNdLCx8zK2p0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy+wO0itRPmekp1g3LTgtPHE8PTwFx1xc2dJSFhVbdkestdk6ke Z2NnmfNmfwzU0TdBAYFsyTcm+xtejfs2roDqGm3HAlwApLPk9kErKAJyttIh13tmZnE= X-Gm-Gg: AR+sD12ZpWW1MnLPP0GQtAVjdA1mr6obZNcGRQXz401TEr6URj74Ela8qf+/7MdpyfF wH1GDbesAgwT7nFbsOHQ+uuY1nqRMEf7Uwk3kFQu6H87sRQ0zzUFfZp2Vg8IZBQwE+Ej9GQt4E4 sOzYOQ7yg/6GSzOZs2Cwzp5N9CiN7Qv1CYM/3cAtptwtYCcnsI+zLhekjsCuRt3MEcWEVrC4uuA xea7MjJBUBZKbl5DEDLfgsmq4ZaD/Fv0YbG+1wbK65ZWa4Ya81jq05PV8aJDTAcinlDc5vZTdxf zhFrknJ0/CBz/PfhGjADNYOIMC5d9+tklUXQJSrr8sUR4DBVHnnl7Fw1Egei5924rNfalqdkB58 8OiVz5Zav8mC7MJpRVE2qQ/H8yeajff8MxOIgThgvD6XiBKTWPuxRdG6W0bXnBjcOcjku2g1xrI Ks2AZ+334ZNqeqlzr+HPOqCR/J9bxPJyrF X-Received: by 2002:a05:600c:6b6a:b0:495:3f0f:d515 with SMTP id 5b1f17b1804b1-49573cf4d25mr17400085e9.36.1784798442830; Thu, 23 Jul 2026 02:20:42 -0700 (PDT) Received: from [192.168.0.161] (78-154-15-182.ip.btc-net.bg. [78.154.15.182]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85b9a659sm14557268f8f.6.2026.07.23.02.20.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2026 02:20:42 -0700 (PDT) Message-ID: Date: Thu, 23 Jul 2026 12:20:40 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 0/5] bridge: Validate and clean up IPv6 neighbour suppression Content-Language: en-US, bg To: Danielle Ratson , "netdev@vger.kernel.org" Cc: "dsahern@kernel.org" , Ido Schimmel , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "horms@kernel.org" , "ja@ssi.bg" , Petr Machata , "fw@strlen.de" , "kuniyu@google.com" , "bridge@lists.linux.dev" , "linux-kernel@vger.kernel.org" References: From: Nikolay Aleksandrov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 23/07/2026 09:40, Danielle Ratson wrote: >> -----Original Message----- >> From: Nikolay Aleksandrov >> Sent: Monday, 20 July 2026 12:31 >> To: Danielle Ratson ; netdev@vger.kernel.org >> Cc: dsahern@kernel.org; Ido Schimmel ; >> davem@davemloft.net; edumazet@google.com; kuba@kernel.org; >> pabeni@redhat.com; horms@kernel.org; ja@ssi.bg; Petr Machata >> ; fw@strlen.de; kuniyu@google.com; >> bridge@lists.linux.dev; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH net-next 0/5] bridge: Validate and clean up IPv6 >> neighbour suppression >> >> On 19/07/2026 16:34, Danielle Ratson wrote: >>> The bridge implements IPv6 neighbour suppression by snooping Neighbour >>> Solicitation and Neighbour Advertisement messages, but it previously >>> only checked the ICMPv6 type and code before acting on them. This >>> leaves it open to acting on malformed or spoofed packets that any RFC >>> 4861 compliant node should reject, and the option parsing in >>> br_nd_send() open-codes a loop that has historically been a source of bugs. >>> >>> This series hardens and cleans up that path: >>> >>> Add ndisc_check_ns_na(), a standalone NS/NA validator modeled after >>> ipv6_mc_check_mld(), implementing the RFC 4861 section 7.1.1 / 7.1.2 >>> mandatory receive checks (hop limit, checksum, code, length, target >>> and option validation). Wire the bridge into it so NS/NA messages are >>> validated to the same standard MLD already enjoys. >>> >>> Replace the manual ND option parsing loop in br_nd_send() with >>> ndisc_parse_options() and ndisc_opt_addr_data(), and linearize the skb >>> once it has been validated as an NS/NA message so that this and any >>> future ND message handling operate on a linear buffer. The first patch >>> is a small preparatory cleanup that drops the now-unnecessary >>> skb_header_pointer() fallback from br_is_nd_neigh_msg(). >>> >>> No functional change is intended for well-formed packets. >>> >>> Patchset overview: >>> Patch #1: drop the skb_header_pointer() fallback. >>> Patches #2-#3: add ndisc_check_ns_na() and validate NS/NA with it. >>> Patch #4: linearize once the ND message type is validated. >>> Patch #5: parse options via ndisc_parse_options(). >>> >>> Danielle Ratson (5): >>> bridge: Use direct pointer in br_is_nd_neigh_msg() >>> ipv6: ndisc: Add ndisc_check_ns_na() validation helper >>> bridge: Validate NS/NA messages using ndisc_check_ns_na() >>> bridge: Linearize skb once the ND message type is validated >>> bridge: Use ndisc_parse_options() to parse ND options in >>> br_nd_send() >>> >>> include/net/ndisc.h | 2 + >>> net/bridge/br_arp_nd_proxy.c | 54 +++++----- >>> net/bridge/br_device.c | 4 +- >>> net/bridge/br_input.c | 4 +- >>> net/bridge/br_private.h | 2 +- >>> net/ipv6/Makefile | 2 +- >>> net/ipv6/ndisc.c | 1 + >>> net/ipv6/ndisc_snoop.c | 190 >> +++++++++++++++++++++++++++++++++++ >>> 8 files changed, 224 insertions(+), 35 deletions(-) >>> create mode 100644 net/ipv6/ndisc_snoop.c >>> >> >> Nice set, but I'm curious - any reason not to use EXPORT_SYMBOL_GPL() >> instead? >> > > I guess you are referring to ndisc_parse_options and ndisc_check_ns_na? > The reason is basically that other sibling functions used EXPORT_SYMBOL() rather than EXPORT_SYMBOL_GPL() (ndisc_send_skb, ndisc_ns_create, and the ndisc_check_ns_na() equivalent in mld, ipv6_mc_check_mld()). > However, ndisc_send_na() for example is newer and uses EXPORT_SYMBOL_GPL(). So it might make sense to use that in ndisc_parse_options(), if you prefer. > Yep, I was referring to those newly exported symbols. Personally I'd always go for the _GPL variant when possible, but it's not a strong preference, more a personal one. I was just curious if there was some particular reason not to be. :) Thanks, Nik >> Cheers, >> Nik