[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFSKS=Mdvsqo0KUqTMdRgJMQ1SSa45wYJ_YM=rqnFEFJBoxZHw@mail.gmail.com>
Date: Tue, 25 May 2021 16:46:21 -0500
From: George McCollister <george.mccollister@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Murali Karicheri <m-karicheri2@...com>,
Taehee Yoo <ap420073@...il.com>,
Kurt Kanzenbach <kurt@...utronix.de>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Wang Hai <wanghai38@...wei.com>,
Phillip Potter <phil@...lpotter.co.uk>,
Andreas Oetken <andreas.oetken@...mens.com>,
Marco Wenzel <marco.wenzel@...berle.de>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] net: hsr: fix mac_len checks
On Mon, May 24, 2021 at 4:29 PM Vladimir Oltean <olteanv@...il.com> wrote:
[snip]
> > + ret = hsr->proto_ops->fill_frame_info(proto, skb, frame);
>
> Nitpick: hsr uses "res", not "ret".
>
Oops. I'll try to pay more attention to what is used in the existing
code next time.
[snip]
>
> I admit that I went through both patches and I still don't understand
> what is the code path that the original commit 2e9f60932a2c ("net: hsr:
> check skb can contain struct hsr_ethhdr in fill_frame_info") is
> protecting against. I ran the C reproducer linked by syzbot too and I
> did not reproduce it (I did not compile with the linked clang though).
I think it's complaining if you access more than mac_len bytes from
the pointer returned by skb_mac_header() but I'm not familiar with
this bot.
Thanks for testing the patch.
-George
Powered by blists - more mailing lists