public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: "Marc Suñé" <marcdevel@gmail.com>
To: kuba@kernel.org, willemdebruijn.kernel@gmail.com, pabeni@redhat.com
Cc: netdev@vger.kernel.org, dborkman@kernel.org,
	vadim.fedorenko@linux.dev, "Marc Suñé" <marcdevel@gmail.com>
Subject: [PATCH net-next v4 0/4] discard ARP/NDP b/mcast/null announce (poison)
Date: Sat,  7 Feb 2026 21:40:32 +0100	[thread overview]
Message-ID: <cover.1770399836.git.marcdevel@gmail.com> (raw)

The current ARP and NDP implementations accept announcements with
multicast (broadcast incl.) and null MAC addresses as Sender HW Address
(SHA) in ARP or src/target lladdr in NDP, and updates the cache
for that neighbour.

Multicast (incl. broadcast) and null MAC addresses shall never be
associated with a unicast or a multicast IPv4/6 address (see RFC1812,
section 3.3.2).

ARP/NDP poisioning with a broadcast and certain multicast MAC addresses,
especially when poisoning a Gateway IP, have some undesired implications
compared to an ARP/NDP poisioning with a regular MAC (see commit message
in patch 1 for more information).

Worth mentioning that if an attacker is able to ARP/NDP poison in
a L2 segment, that in itself is probably a bigger security threat
(Man-in-middle etc., see Note2 in patch 1)

Since these MACs should never be announced, this patch series discards/drops
these packets, which prevents broadcast and multicast ARP/NDP poisoning
vectors.

This patchset only modifies the behaviour of the neighbouring subsystem
when processing network packets. Static entries can still be added with
mcast/bcast/null MACs.

v3: https://lore.kernel.org/netdev/cover.1770241104.git.marcdevel@gmail.com/
v2: https://lore.kernel.org/netdev/cover.1769464405.git.marcdevel@gmail.com/
v1: https://lore.kernel.org/netdev/cover.1766349632.git.marcdevel@gmail.com/

Changes since v3
================
  - Respin rebase on top net-next

Changes since v2
================
  - Target net-next instead of net
  - Use mausezahn for patch2 and remove arp_send.c
  - Kept ndisc_send.c for patch 4, as ndisc6 and mausezahn are not valid
    options (see comment)
  - Fixed comment llsrc->lltgt (AI review)
  - Misc fixes: shellcheck, alphabetical order in Makefile

Changes since RFC v1
====================
  - Discard announcements with multicast MAC addresses
  - Check for dev->type == ARPHRD_ETHER instead of HW addrlen in ARP
  - Use !is_valid_ether_addr()
  - Added multicast test coverage and renamed tests accordingly
  - Dropped patch 5 (scapy utils)

Comments
========

On `ndisc_send.c` alternatives, ndisc6 and extending mausezahn were not viable
options. Submitted with `ndisc_send.c`, as preferred by maintainers.

Having said that, I still think Scapy is the best tool for these sort of packet
generation, and can simplify - perhaps at a cost of some test execution time -
selftest creation and maintenance. As also mentioned in
../bpf/generate_udp_fragments.py, it's sort of industry standard, and is widely
used for dataplane functional testing. I've personally used it in several
organizations to functionally test ASICs, NPUs and SW datapaths.

If maintainers are willing to reconsider that, I'd be happy to work on
transitioning the existing selftests (using ndisc6, mausezahn...) towards Scapy.

Marc Suñé (4):
  arp: discard invalid sha addr (b/mcast ARP poison)
  selftests/net: add no ARP b/mcast,null poison test
  neigh: discard invalid lladdr (b/mcast poison)
  selftests/net: add no NDP b/mcast,null poison test

 net/ipv4/arp.c                                |   8 +
 net/ipv6/ndisc.c                              |  16 +
 tools/testing/selftests/net/.gitignore        |   1 +
 tools/testing/selftests/net/Makefile          |   3 +
 .../net/arp_ndisc_no_invalid_sha_poison.sh    | 368 ++++++++++++++++++
 tools/testing/selftests/net/ndisc_send.c      | 198 ++++++++++
 6 files changed, 594 insertions(+)
 create mode 100755 tools/testing/selftests/net/arp_ndisc_no_invalid_sha_poison.sh
 create mode 100644 tools/testing/selftests/net/ndisc_send.c

-- 
2.47.3


             reply	other threads:[~2026-02-07 20:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-07 20:40 Marc Suñé [this message]
2026-02-07 20:40 ` [PATCH net-next v4 1/4] arp: discard invalid sha addr (b/mcast ARP poison) Marc Suñé
2026-02-07 20:40 ` [PATCH net-next v4 2/4] selftests/net: add no ARP b/mcast,null poison test Marc Suñé
2026-02-11  2:11   ` Jakub Kicinski
2026-02-11 18:29     ` Marc Sune
2026-02-11 18:49       ` Jakub Kicinski
2026-02-07 20:40 ` [PATCH net-next v4 3/4] neigh: discard invalid lladdr (b/mcast poison) Marc Suñé
2026-02-07 20:40 ` [PATCH net-next v4 4/4] selftests/net: add no NDP b/mcast,null poison test Marc Suñé
2026-02-11  2:11   ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1770399836.git.marcdevel@gmail.com \
    --to=marcdevel@gmail.com \
    --cc=dborkman@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=vadim.fedorenko@linux.dev \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox