netdev - Re: [PATCH 0/3] Check gso_size of packets when forwarding

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180122.151453.1675721993605626060.davem@davemloft.net>
Date:   Mon, 22 Jan 2018 15:14:53 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     pshelar@....org
Cc:     dja@...ens.net, netdev@...r.kernel.org, Manish.Chopra@...ium.com,
        dev@...nvswitch.org
Subject: Re: [PATCH 0/3] Check gso_size of packets when forwarding

From: Pravin Shelar <pshelar@....org>
Date: Fri, 19 Jan 2018 13:54:15 -0800

> I agree it is not perfect. But the other proposed patch does not fix
> the connectivity issue. It only adds log msg in such cases at cost
> of extra checks/code. Therefore I prefer the easier fix for the
> issue which also fixes for all cases of packet forwarding rather
> than just OVS and Bridge.

I really think that something needs to guarantee that device drivers
will never be given either over-MTU or over-max-GSO-seg-size SKBs.

Otherwise drivers need to add completely stupid checks like making
sure that SKB lengths do not exceed the maxmimu value that can be
encoded into descriptors.

What's probably happening often now in such situations is that the
driver ends up masking the length blindly and ends up sending out a
truncated packet.

Which frankly is quite bad too.

It doesn't scale to add these checks into every driver, or trying to
"figure out" which drivers will behave adversely and only add checks
to those.

The kernel shouldn't pass objects with out-of-range attributes
to the driver, period.