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  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:	Fri, 16 Mar 2012 16:25:32 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	George Spelvin <linux@...izon.com>
Cc:	jack@...e.cz, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: Oops in ext3_block_to_path.isra.40+0x26/0x11b

On Fri, 16 Mar 2012, George Spelvin wrote:

> > I am not aware of anything, but I have a question -- George, did the 
> > machine get suspended/resumed before this happened?
> 
> I'm pretty sure it didn't.  It's a desktop machine, and I don't ever
> suspend it.  It had been up for a while, and /sys/power/state exists, and
> *maybe* I played with it sometime since boot, but the backup runs nightly
> and I *definitely* did not suspend it the day (or even several days)
> before the oops.
> 
> (I tried to preserve the machine state, but processes started getting
> stuck in the kernel a few hours after the report, so I had to reboot it.)
> 
> Jan Kara asked:
> >   And by any chance, do you use i915 driver? Because that one seems to
> > cause corruption - see: https://lkml.org/lkml/2012/3/9/217. I believe
> > Jiri's corruption is likely caused by that...
> 
> Yes!  lspci -nn and abbreviated .config attached.  But, as mentioned, the machine
> hasn't been suspended...

So it might be the culprit. As the reason of the corruption is not yet 
understood, it might be that suspend/resume cycle is not necessary 
pre-requisite for this to trigger, it might just make it more likely.

And the corruption is observed to be indeed several writes of 0x00000000, 
so it could easily lead to null pointer dereferences all over the place.

Are you able to reproduce the problem if you turn kernel modesetting off?

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

Powered by blists - more mailing lists