netdev - Re: Question about dev_validate_header used in af

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 7 Sep 2020 14:16:36 -0700
From:   Xie He <xie.he.0141@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question about dev_validate_header used in af_packet.c

On Mon, Sep 7, 2020 at 2:06 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> The CAP_SYS_RAWIO exception indeed was requested to be able to
> purposely test devices against bad inputs. The gmane link
> unfortunately no longer works, but this was the discussion thread:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg99920.html
>
> It zeroes the packet up max_header_len to ensure that an unintentional
> short packet will at least not result in reading undefined data. Now
> that the dust has settled around the min_header_len/max_header_len
> changes, maybe now is a good time to revisit removing that
> CAP_SYS_RAWIO loophole.

Thank you for your explanation! I can now understand the logic of
dev_hard_header. Thanks!

Do you mean we can now consider removing the ability to bypass the
header_ops->validate check? That is what I am thinking about, too!

I looked at the link you gave me. I see that Alan Cox wanted to keep
the ability of intentionally feeding corrupt frames to drivers, to
test whether drivers are able to handle incomplete headers. However, I
think after we added the header validation in af_packet.c, drivers no
longer need to ensure they can handle incomplete headers correctly
(because this is already handled by us). So there's no point in
keeping the ability to test this, either.