linux-kernel - Re: [PATCH net-next v6 4/5] net: hdlc_fr: Improve the initial checks when we receive an skb

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:   Sat, 31 Oct 2020 10:05:54 -0700
From:   Xie He <xie.he.0141@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Krzysztof Halasa <khc@...waw.pl>
Subject: Re: [PATCH net-next v6 4/5] net: hdlc_fr: Improve the initial checks
 when we receive an skb

On Fri, Oct 30, 2020 at 5:49 PM Xie He <xie.he.0141@...il.com> wrote:
>
> Add an fh->ea2 check to the initial checks in fr_rx. fh->ea2 == 1 means
> the second address byte is the final address byte. We only support the
> case where the address length is 2 bytes. If the address length is not
> 2 bytes, the control field and the protocol field would not be the 3rd
> and 4th byte as we assume. (Say it is 3 bytes, then the control field
> and the protocol field would be the 4th and 5th byte instead.)

No, I don't think adding this explanation (about why address lengths
other than 2 are not supported) is necessary. The code of this driver
completely doesn't support address lengths other than 2 for many
reasons, not only the reason above. The code for parsing and
generating the address field (q922_to_dlci and dlci_to_q922) supports
only 2-byte address fields. Also, the structure of the sending code of
this driver can only generate headers with a 2-byte address field.
Frame Relay networks usually have a fixed address length, that means a
certain network usually has only 1 fixed address length. If this
driver sends frames with 2-byte address fields, it shouldn't expect it
would receive frames with 3-byte or 4-byte address fields. There are
too many reasons, and I think just saying we only support 2-byte
address fields is completely enough. Explaining the reason as above
seems weird and inadequate to me, and also unnecessary to me.

Therefore, I will resend this patch series with this explanation
(about why address lengths other than 2 are not supported) removed.