linux-kernel - Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

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: <20121020180437.GA9301@liondog.tnic>
Date:	Sat, 20 Oct 2012 20:04:37 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"Artem S. Tashkinov" <t.artem@...os.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Re: A reliable kernel panic (3.6.2) and system crash when
 visiting a particular website

On Sat, Oct 20, 2012 at 05:41:49PM +0000, Artem S. Tashkinov wrote:
> On Oct 20, 2012, Borislav Petkov wrote: 
> 
> > Yeah, your kernel is tainted with a proprietary module (vbox*, etc). Can
> > you reproduce your corruptions (this is what it looks like) without that
> > module?
> 
> Yes, I can reproduce this panic with zero proprietary/non-free modules loaded.
> 
> The problem is the kernel doesn't even print a kernel panic - the
> system just freezes completely - cursor in a text console stops blinking.
> 
> I have no means to debug it using a serial console - what can I do?

Ok, here's what you can try:

* You say this happens with google chrome. Does it happen if you use
another browser: firefox, etc?

* Can you build a 64-bit kernel and try the same with it? The 32-bit
userspace should work in compat mode just fine.

* Can you run memtest on your machine and check whether your DIMMs
aren't generating ECC errors? Are your DIMMs ECC, btw?

* What about netconsole? You only need another machine on the same
network: Documentation/networking/netconsole.txt.

* boot with "pause_on_oops=600" on the kernel command line to stop the
machine for 600 secs after the first oops happens. Then try to make a
photo of the screen. Make sure to disable X or to be on a text console
so that you can see the oops.

* Try enabling a bunch of debugging options in "Kernel hacking". More
specifically,

CONFIG_DETECT_HUNG_TASK
CONFIG_DEBUG_PREEMPT
CONFIG_DEBUG_SPINLOCK
CONFIG_DEBUG_MUTEXES
CONFIG_DEBUG_LOCK_ALLOC
CONFIG_PROVE_LOCKING
CONFIG_PROVE_RCU
CONFIG_DEBUG_ATOMIC_SLEEP
CONFIG_DEBUG_BUGVERBOSE
CONFIG_DEBUG_INFO
CONFIG_DEBUG_VM
CONFIG_DEBUG_VIRTUAL
CONFIG_DEBUG_MEMORY_INIT
CONFIG_DEBUG_LIST
CONFIG_X86_VERBOSE_BOOTUP
CONFIG_DEBUG_RODATA
...

I hope those should scream in case something goes awry.

HTH.

-- 
Regards/Gruss,
    Boris.
--
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/