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]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6E8463@AcuExch.aculab.com>
Date:	Tue, 25 Mar 2014 09:37:12 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Alon Nafta' <alon@...vatecore.com>,
	Ben Hutchings <ben@...adent.org.uk>
CC:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	"Grant Grundler" <grantgrundler@...il.com>
Subject: RE: [PATCH 1/4 V2] Ethernet drivers in 3.14-rc3 kernel: fix 3
 buffer overflows triggered by hardware devices

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



--
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