Re: [PATCH net-next 0/5] bridge: Validate and clean up IPv6 neighbour suppression

On 23/07/2026 09:40, Danielle Ratson wrote:
>> -----Original Message-----
>> From: Nikolay Aleksandrov <[email protected]>
>> Sent: Monday, 20 July 2026 12:31
>> To: Danielle Ratson <[email protected]>; [email protected]
>> Cc: [email protected]; Ido Schimmel <[email protected]>;
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]; Petr Machata
>> <[email protected]>; [email protected]; [email protected];
>> [email protected]; [email protected]
>> 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