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]

Message-ID: <1528536.jyty2pu4Mz@sifl>
Date:	Tue, 20 Jan 2015 19:14:46 -0500
From:	Paul Moore <pmoore@...hat.com>
To:	Sabrina Dubroca <sd@...asysnail.net>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	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 Tuesday, January 20, 2015 07:04:54 PM Paul Moore wrote:
> On Wednesday, January 21, 2015 12:27:26 AM Sabrina Dubroca wrote:
> > 2015-01-20, 23:17:25 +0000, Al Viro wrote:
> > > On Tue, Jan 20, 2015 at 10:50:41PM +0000, Al Viro wrote:
> > > > doesn't look at _anything_ other than name->name other than for
> > > > audit_inode(). And name->name is apparently the same.
> > > > 
> > > > It looks like something ends up buggering name->name in process, but
> > > > then
> > > > the damn thing appears to be normal after return from
> > > > filename_lookup()...
> > > 
> > > If my reconstruction of what's going on is correct, the call chain here
> > > is do_path_lookup() <- kern_path() <- lookup_bdev() <-
> > > blkdev_get_by_path()
> > > <- mount_bdev() <- some_type.mount() <- mount_fs()
> > > <- vfs_kern_mount() <- do_new_mount() <- do_mount() <- sys_mount()
> > > <- do_mount_root() <- mount_block_root() <- mount_root().  Which is
> > > obscenely long, BTW, but that's a separate story...
> > > 
> > > Could you slap
> > > 
> > > 	struct stat buf;
> > > 	int n = sys_newstat(name, &buf);
> > > 	printk(KERN_ERR "stat(\"%s\") -> %d\n", name, n);
> > > 	n = sys_newstat("/dev", &buf);
> > > 	printk(KERN_ERR "stat(\"dev\") -> %d\n", n);
> > > 
> > > in the beginning of mount_block_root() (init/do_mounts.c) and see what
> > > it
> > > prints?
> > 
> > I get
> > 
> > stat("/dev/root") -> -2
> > stat("dev") -> -2
> > 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 ...

Could you try initializing the init_task's audit_context to NULL in the 
INIT_TASK macro in include/linux/init_task.h?

Example:

 #define INIT_TASK(tsk)
 {
   .state          = 0,
   .stack          = &init_thread_info,
 ...
   .audit_context  = NULL,
 ...
 }

-- 
paul moore
security @ redhat

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