linux-kernel - Re: Crash on reading the whole PCI config of PIIX4 SMBus

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: <4ABA4382.1000707@nachtwindheim.de>
Date:	Wed, 23 Sep 2009 17:49:22 +0200
From:	Henrik Kretzschmar <henne@...htwindheim.de>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	Wolfram Sang <w.sang@...gutronix.de>, linux-pci@...r.kernel.org,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Crash on reading the whole PCI config of PIIX4 SMBus

Jean Delvare schrieb:

> That's right, but it doesn't explain why i2c-piix4 crashes in the first
> place, not why merely loading it causes further lspci -xxx to crash
> when they did not beforehand. I admit I am totally clueless.
>   
Sorry, I expressed myself a bit unclear.

With _worked_ I meant the system crashed (thats what killer commands are for).

lspci -xxx (and co) bring this system down in every case, module loaded or not.
Obvious this crash occuress when reading the config space in short periods.

lspci (or better proc-fs and sys-fs) do that, and i2c-piix4 does it sometimes.

Looking at read() of drivers/pci/proc.c i had the idea of stalking the critical area with:

#!/bin/sh
for i in `seq 100`; do
 dd if=/proc/bus/pci/00/07.3 of=/dev/null bs=1 count=n 2>/dev/null;
done

I got no crashes with n == 192, but with n == 193 theres no reaction from the system.

Maybe it's interesting, that (all the time after crashes) the screen
(in my case the console with a blinking cursor) can still be seen.
But no reaction on keyboard hits.

Also strange is, that the device works well IF those two read accesses have not done the crash.
I'll test tomorrow without the second read access, just to know if it works.

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