[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLam6JDbJ3NJ3cRs1fnDz2HAN_gMhAn0SewoYbqBLbW4w@mail.gmail.com>
Date: Fri, 12 Jan 2024 14:11:43 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Willem de Bruijn <willemb@...gle.com>, netdev@...r.kernel.org,
eric.dumazet@...il.com, syzbot+7f4d0ea3df4d4fa9a65f@...kaller.appspotmail.com
Subject: Re: [PATCH net] net: add more sanity check in virtio_net_hdr_to_skb()
On Fri, Jan 12, 2024 at 2:00 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Fri, Jan 12, 2024 at 01:28:16PM CET, edumazet@...gle.com wrote:
> >syzbot/KMSAN reports access to uninitialized data from gso_features_check() [1]
> >
> >The repro use af_packet, injecting a gso packet and hdrlen == 0.
> >
> >We could fix the issue making gso_features_check() more careful
> >while dealing with NETIF_F_TSO_MANGLEID in fast path.
> >
> >Or we can make sure virtio_net_hdr_to_skb() pulls minimal network and
> >transport headers as intended.
>
> You describe "either or", but don't really say what to do. Bit
> confusing :/
Not sure I understand your point?
Patch title is " net: add more sanity check in virtio_net_hdr_to_skb() ",
and the change is implementing that option.
I am saying I prefer not touching gso_features_check(), even if we
could just do this.
Had I been silent about that option, I am sure some reviewers would
have raised the question,
given the stack trace ?
Apparently you are saying these kinds of things should not be ever mentioned,
because of some "imperative mood" request that you often raise with my patches.
I have not written a novel, only one sentence, admittedly not written
in perfect English.
Powered by blists - more mailing lists