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:	Fri, 20 May 2016 20:56:34 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Tom Herbert <tom@...bertland.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for
 unsupported GSO

On Fri, May 20, 2016 at 6:02 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> Hello,
>
> On 18.05.2016 18:06, Tom Herbert wrote:
>> In several gso_segment functions there are checks of gso_type against
>> a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
>> attempt to identify unsupported GSO types, but since the stack is
>> the one that set these GSO types in the first place this seems
>> unnecessary to do. If a combination isn't valid in the first
>> place that stack should not allow setting it.
>>
>> This is a code simplication especially for add new GSO types.
>
> I couldn't still wrap my head around this.
>
> I wonder if this is safe in case of if the packet is generated from an
> untrusted virtual machine over virtio_net?

The problem is the test is kind of pointless.  I think the original
point of the tests was to prevent the case of IPIP and TSO6 or SIT and
TSO4.  However since we dropped IPIP and SIT and instead replaced them
with the IPXIP6 and IPXIP4 there shouldn't be any combinations that
don't work now other than UDP being combined with TCP segmentation.

If we are wanting to prevent that case we might place something
earlier in the segmentation code that would perform an and with all
the L4 GSO types that should be mutually exclusive, verify that value
is non-zero, and then and that value with itself - 1 to verify that
exactly 1 bit is set in that grouping and no more than that.

- Alex

Powered by blists - more mailing lists