From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Marc Sune <marcdevel@gmail.com>
Cc: kuba@kernel.org, willemdebruijn.kernel@gmail.com,
pabeni@redhat.com, netdev@vger.kernel.org, dborkman@kernel.org
Subject: Re: [PATCH RFC net 1/5] arp: discard sha bcast/null (bcast ARP poison)
Date: Mon, 22 Dec 2025 22:08:59 +0000 [thread overview]
Message-ID: <c2c9959f-8df0-4a78-8064-733a643351fc@linux.dev> (raw)
In-Reply-To: <CA+3n-TrGSs-rPswMmCaUjYnM=f1APBWtmAguMUaAOvwuKm30+Q@mail.gmail.com>
On 22/12/2025 21:37, Marc Sune wrote:
> Missatge de Vadim Fedorenko <vadim.fedorenko@linux.dev> del dia dl.,
> 22 de des. 2025 a les 10:47:
>>
>> On 21/12/2025 21:19, Marc Suñé wrote:
>>>
>>> /*
>>> + * For Ethernet devices, Broadcast/Multicast and zero MAC addresses should
>>> + * never be announced and accepted as sender HW address (prevent BCAST MAC
>>> + * and NULL ARP poisoning attack).
>>> + */
>>> + if (dev->addr_len == ETH_ALEN &&
>>
>> dev_type == ARPHRD_ETHER ?
>
> This is discussed in the cover letter, comments section d). I would
> think more dev_types than that need to check this, at least:
>
> + case ARPHRD_ETHER:
> + case ARPHRD_EETHER:
> + case ARPHRD_FDDI:
> + case ARPHRD_IEEE802:
> + case ARPHRD_IEEE80211:
>
> but as said, I _think_ it's sufficient to check for HW addrlen == ETH_ALEN.
ARPHRD_EETHER and ARPHRD_IEEE80211 are not really used in the kernel.
For other 3 we already have such case a bit earlier in arp_process(),
it's fine to be aligned with the existing code.
>
>>
>>
>>> + (is_broadcast_ether_addr(sha) || is_zero_ether_addr(sha)))
>>
>> RFC says that neither broadcast, nor multicast must be believed. You
>> check for broadcast only. The better check would be:
>>
>> !is_unicast_ether_addr(sha)
>
> This is discussed in the cover letter, comments section b). In short,
> some NLBs announce MCAST MAC addresses.
>
> Mind the context there, but I think it's safe. This is applicable to
> ARP and NDP, so I would suggest to follow up there.
>
> Btw, the is_zero_ether_addr(addr) check is still needed.
> is_unicast_ether_addr(addr) is implemented as
> !is_multicast_ether_addr(addr), and the NULL mac (00:00:00:00:00:00)
> doesn't have the "MCAST bit" set to 1.
Yeah, "!is_valid_ether_addr(sha)" is better in this case.
>
>>
>>> + goto out_free_skb;
>>> +
>>> + /*
>>> * Special case: We must set Frame Relay source Q.922 address
>>> */
>>> if (dev_type == ARPHRD_DLCI)
>>
next prev parent reply other threads:[~2025-12-22 22:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-21 21:19 [PATCH RFC net 0/5] net: discard ARP/NDP bcast/null announce (poison) Marc Suñé
2025-12-21 21:19 ` [PATCH RFC net 1/5] arp: discard sha bcast/null (bcast ARP poison) Marc Suñé
2025-12-22 9:47 ` Vadim Fedorenko
2025-12-22 21:37 ` Marc Sune
2025-12-22 22:08 ` Vadim Fedorenko [this message]
2025-12-21 21:19 ` [PATCH RFC net 2/5] selftests/net: add no ARP bcast/null poison test Marc Suñé
2025-12-21 21:19 ` [PATCH RFC net 3/5] neigh: discard lladdr bcast/null (bcast poison) Marc Suñé
2025-12-21 21:19 ` [PATCH RFC net 4/5] selftests/net: add no NDP bcast/null poison test Marc Suñé
2025-12-21 21:19 ` [PATCH RFC net 5/5] selftests/net: use scapy for no_bcastnull_poison Marc Suñé
2025-12-22 9:34 ` Vadim Fedorenko
2025-12-22 21:46 ` Marc Sune
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=c2c9959f-8df0-4a78-8064-733a643351fc@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=dborkman@kernel.org \
--cc=kuba@kernel.org \
--cc=marcdevel@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.