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]
Message-ID: <12cfe9e36292a94b8492c0747f0d9ce1e781ae20.camel@redhat.com>
Date:   Mon, 17 May 2021 09:47:59 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Willem de Bruijn <willemb@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.10 380/530] udp: never accept GSO_FRAGLIST packets

On Mon, 2021-05-17 at 08:57 +0200, Pavel Machek wrote:
> From: Paolo Abeni <pabeni@...hat.com>
> > > > 
> > > > [ Upstream commit 78352f73dc5047f3f744764cc45912498c52f3c9 ]
> > > > 
> > > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > > the sockets without the expected segmentation.
> > > > 
> > > > This change addresses the issue introducing and maintaining
> > > > a couple of new fields to explicitly accept SKB_GSO_UDP_L4
> > > > or GSO_FRAGLIST packets. Additionally updates  udp_unexpected_gso()
> > > > accordingly.
> > > > 
> > > > UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist
> > > > zeroed.
> > > 
> > > What is going on here? accept_udp_fraglist variable is read-only.
> > 
> > Thank you for checking this!
> > 
> > The 'accept_udp_fraglist' field is implicitly initilized to zero at UDP
> > socket allocation time (done by sk_alloc).
> > 
> > So this patch effectively force segmentation of SKB_GSO_FRAGLIST
> > packets via the udp_unexpected_gso() helper.
> > 
> > We introduce the above field instead of unconditionally
> > segmenting SKB_GSO_FRAGLIST, because the next patch will use it (to
> > avoid unneeded segmentation for performance's sake for UDP tunnel), as
> > you noted.
> 
> Ok, but there's no follow up patch queued for 5.10...? Do we still
> need it there?

Patch d18931a92a0b5feddd8a39d097b90ae2867db02f is a performance
improvement, I think not worthy/suitable for stable.

For 5.10 78352f73dc5047f3f744764cc45912498c52f3c9 should be enough.

Thanks!

Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ