netdev - Re: [PATCH 1/4 V2] Ethernet drivers in 3.14-rc3 kernel: fix 3 buffer overflows triggered by hardware devices

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:	Tue, 25 Mar 2014 10:26:21 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Grant Grundler <grantgrundler@...il.com>
Cc:	David Laight <David.Laight@...lab.com>,
	Alon Nafta <alon@...vatecore.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/4 V2] Ethernet drivers in 3.14-rc3 kernel: fix 3
 buffer overflows triggered by hardware devices

On Tue, 2014-03-25 at 09:19 -0700, Grant Grundler wrote:
> On Tue, Mar 25, 2014 at 2:37 AM, David Laight <David.Laight@...lab.com> wrote:
> > From: Alon Nafta
> >> I don't think they should be trusted at all, at least not to a point
> >> where it's feasible for them to execute code on your system.
> >> USB drivers, filesystem drivers, peripheral drivers - they're all on
> >> the same boat, obviously having different levels of severity depending
> >> on driver popularity.
> >
> > On a large number of systems any PCI or PCIe hardware has the
> > ability to read and write any system physical addresses.
> > Not only does this mean that 'dodgy' hardware can change the
> > kernel code, but also any attempt to restrict the memory that
> > the driver itself can access is likely to be circumventable.
> >
> > Yes, you can raise the barrier, but there will always be low
> > points on it.
> 
> David, Alon,
> your points are valid but getting a bit philosophical for me.
> 
> The original patch was trying to address *abuse* of the tulip chip and
> it's not clear to me that's really feasible.  I think this patch is
> "safe" in the sense it enforces correct behavior and AFAICT adds no
> additional CPU cost.

BTW this reminds me :

 http://lkml.iu.edu//hypermail/linux/kernel/1003.3/02073.html

Some hardware have some flaws, not because its malicious but plainly
buggy, and its reasonable to take some basic checks on common 'mistakes'

Checking that the NIC doesn't pretend to receive a bigger frame than the
expected maximum seems reasonable.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html