linux-kernel - Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

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, 23 Sep 2008 21:12:15 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jkosina@...e.cz
Cc:	jeffrey.t.kirsher@...el.com, airlied@...il.com,
	david.vrabel@....com, rjw@...k.pl, linux-kernel@...r.kernel.org,
	kernel-testers@...r.kernel.org, chrisl@...are.com
Subject: Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

From: Jiri Kosina <jkosina@...e.cz>
Date: Wed, 24 Sep 2008 00:19:00 +0200 (CEST)

> On Tue, 23 Sep 2008, Jeff Kirsher wrote:
> 
> > >> I don't think OpenSUSE was shipping any of the GEM bits.
> > > Good data point, can someone confirm this?  Also, what X server version
> > > is the effected OpenSUSE shipping?
> > OpenSuSE 11 ships x server version 7.3.
> 
> Opensuse 11 is fine.
> 
> The problem can be reproduced [not only] on opensuse 11.1 beta1, which has
> 
> 	xorg-x11-7.4-1.6.x86_64.rpm

I did some snooping around, and while doing so I noticed that the PCI
mmap code for x86 doesn't do one bit of range checking on the size, or
any other aspect of the request, wrt. the MMIO regions actually mapped
in the BARs of the PCI device.

Yikes!

It just does a reserve_memtype() on the address range, and says "ok".

So if, for example, the X server tries to mmap() more than an MMIO bar
actually maps, the kernel lets the user do this.

It would be very interesting to add the appropriate checks to
pci_mmap_page_range() in arch/x86/pci/i386.c, anyone who wants to do
this can use the code in arch/sparc64/kernel/pci.c:
__pci_mmap_make_offset() as a guide, and see what happens.

If the MMIO space regions of the video cards sit right before the
E1000E ones on the effected systems, that would pretty much
convince me that this is the kind of problem we are having here.

This also reminds me that there was that whole set of issues that
had to get worked out wrt. write-caching of mappings on x86.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/