netdev - Re: [PATCH net] icmp: MUST silently discard certain extended echo requests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADx9qWhEZmkhHE+7cxdwcE1WACGMczV1zJ=S7KQdtzMhX6Hm9w@mail.gmail.com>
Date: Tue, 11 Feb 2025 13:38:03 -0500
From: Will Hawkins <hawkinsw@....cr>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net] icmp: MUST silently discard certain extended echo requests

On Tue, Feb 11, 2025 at 4:12 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On 2/6/25 2:57 AM, Will Hawkins wrote:
> > Per RFC 8335 Section 4,
> > """
> > When a node receives an ICMP Extended Echo Request message and any of
> > the following conditions apply, the node MUST silently discard the
> > incoming message:
> >
> > ...
> > - The Source Address of the incoming message is not a unicast address.
> > - The Destination Address of the incoming message is a multicast address.
> > """
>
> I think it would be helpful mentioning this is for ICMP PROBE extension.

Absolutely.

>
> > Packets meeting the former criteria do not pass martian detection, but
> > packets meeting the latter criteria must be explicitly dropped.
> >
> > Signed-off-by: Will Hawkins <hawkinsw@....cr>
>
> The patch should target the net-next tree, and you should add a related

I am terribly sorry for targeting the wrong tree. I interpreted

"As you can probably guess from the names, the net tree is for fixes
to existing code already in the mainline tree from Linus ..."

incorrectly. I will adjust in the next revision. Sorry again!

> self-test (i.e. extending icmp.sh). Also even if the new behavior will

I will absolutely add a test!

> respect the RFC, changing the established behavior could break existing
> setups, I *think* we would need at least a sysctl to revert to the old one.

I agree and will add such a sysctl! Thank you for the review!
Will

>
> /P
>