linux-kernel - Re: linux-next: Tree for Jan 20 -- Kernel panic

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:	Wed, 21 Jan 2015 00:41:17 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Paul Moore <pmoore@...hat.com>
Cc:	Sabrina Dubroca <sd@...asysnail.net>,
	Guenter Roeck <linux@...ck-us.net>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-audit@...hat.com,
	Richard Guy Briggs <rgb@...hat.com>
Subject: Re: linux-next: Tree for Jan 20 -- Kernel panic - Unable to mount
 root fs

On Tue, Jan 20, 2015 at 07:14:46PM -0500, Paul Moore wrote:
> > > with the patch applied (+panic)
> > > 
> > > 
> > > and:
> > > 
> > > stat("/dev/root") -> 0
> > > stat("dev") -> 0
> > > with the old version of do_path_lookup.
> > 
> > Wait a minute ... at this early stage of boot, I'm pretty sure we don't have
> > a valid current->audit_context since we haven't fork'd anything.  If the
> > audit context was non-NULL garbage that might explain the panic ...

Not really - the panic is predicatable result of not finding /dev/root (hell,
not even /dev there!) in mount_block_root().
 
> Could you try initializing the init_task's audit_context to NULL in the 
> INIT_TASK macro in include/linux/init_task.h?

Missing fields in struct initializer are treated as zeroes.

The shit hits the fan earlier - when we end up missing /dev.  There are
two places where it could've been created (depending on CONFIG_BLK_DEV_INITRD);
	sys_mkdir(collected, mode);
in init/initramfs.c (line 353 in linux-next) and
        err = sys_mkdir((const char __user __force *) "/dev", 0755);
in init/noinitramfs.c (line 32).  The latter would've screamed on failure;
could you printk of collected (%s), mode (%o) and return value (%d) in the
former and see what happens?
--
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/