netdev - Re: [EXT] Re: [PATCH net] qede: validate non LSO skb length

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]

Date:   Thu, 2 Dec 2021 17:19:18 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Manish Chopra <manishc@...vell.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Ariel Elior <aelior@...vell.com>,
        Alok Prasad <palok@...vell.com>,
        Prabhakar Kushwaha <pkushwaha@...vell.com>
Subject: Re: [EXT] Re: [PATCH net] qede: validate non LSO skb length

On Thu, 2 Dec 2021 21:19:26 +0000 Manish Chopra wrote:
> > On Wed, 24 Nov 2021 01:24:05 -0800 Manish Chopra wrote:  
> > > Although it is unlikely that stack could transmit a non LSO skb with
> > > length > MTU, however in some cases or environment such occurrences
> > > actually resulted into firmware asserts due to packet length being
> > > greater than the max supported by the device (~9700B).
> > >
> > > This patch adds the safeguard for such odd cases to avoid firmware
> > > asserts.
> > >
> > > Signed-off-by: Manish Chopra <manishc@...vell.com>
> > > Signed-off-by: Alok Prasad <palok@...vell.com>
> > > Signed-off-by: Prabhakar Kushwaha <pkushwaha@...vell.com>
> > > Signed-off-by: Ariel Elior <aelior@...vell.com>  
> > 
> > Please add an appropriate Fixes tag and repost.  
> 
> Hello Jakub,
> 
> I don't really know which commit has introduced this exactly. It was
> probably day1 (when this driver was submitted) behavior, just that
> this issue was discovered recently by some customer environment. Let
> me know if you want me to put one of those initial driver commit tag
> here and repost ? 

Yes, that'd be best. This way any sort of automation for tracking which
fixes need to be backported will have clear signal that this fix
applies to all the kernels.