linux-kernel - Re: [BUG] OpenRISC exec init fails, bisected to 0886551 ("initramfs: finish fput() before accessing any binary from initramfs")

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 May 2017 18:41:09 +0900
From:   Stafford Horne <shorne@...il.com>
To:     Lokesh Vutla <lokeshvutla@...com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Murali Karicheri <m-karicheri2@...com>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [BUG] OpenRISC exec init fails, bisected to 0886551 ("initramfs:
 finish fput() before accessing any binary from initramfs")

On Thu, May 04, 2017 at 02:39:38PM +0530, Lokesh Vutla wrote:
> 
> 
> On Thursday 04 May 2017 02:05 PM, Stafford Horne wrote:
> > On Thu, May 04, 2017 at 01:15:23PM +0530, Lokesh Vutla wrote:
> >>
> >>
> >> On Thursday 04 May 2017 12:41 PM, Stafford Horne wrote:
> >>> Hello,
> >>>
> >>> While booting the v4.11 kernel I found the below issue.
> >>>
> >>> The summary of the issue mentions
> >>>
> >>>     Commit 4a9d4b024a31 ("switch fput to task_work_add") implements a
> >>>     schedule_work() for completing fput(), but did not guarantee calling
> >>>     __fput() after unpacking initramfs.  Because of this, there is a
> >>>     possibility that during boot a driver can see ETXTBSY when it tries to
> >>>     load a binary from initramfs as fput() is still pending on that binary.
> >>>
> >>> It seems this patch (0886551) introduces that issue though?
> >>>
> >>> I am looking into it, but any suggestions would be helpful.
> >>
> >> Can you check if flush_delayed_fput() is being called? Do you have
> >> CONFIG_INITRAMFS_FORCE enabled?
> > 
> > This is not enabled.  I debugged it and I cant see it getting called.  I
> > see populate_rootfs getting called but initrd_start is 0, I think there is
> > something different happening to unpack in initramfs since ours is compiled
> > in.
> 
> What about __initramfs_start, __initramfs_size?

Those have the correct values.

I think the problem is with openrisc's linker file.

In there we have:

	__initrd_start = .;
	*(.initrd)
	__initrd_end = .;

In setup_arch() we have:

    #ifdef CONFIG_BLK_DEV_INITRD
        initrd_start = (unsigned long)&__initrd_start;
        initrd_end = (unsigned long)&__initrd_end;
        if (initrd_start == initrd_end) {
                initrd_start = 0;
                initrd_end = 0;
        }
        initrd_below_start_ok = 1;
    #endif

That doesnt work because there is nothing in .initrd and __initrd_start is
the same as __initrd_end.

The initramfs gets linked to the location of  __initramfs_start, not
__initrd_start.  I am guessing the above is something very old.

I think I just need to remove all of that __initrd_start/__initrd_end
stuff.

I'll try it out and send a patch later today or tomorrow.  Not much time
now.

> > 
> > I am trying to look into it, but I need to relearn how the initramfs gets
> > initted for OpenRISC.  Perhaps the fix it going to keep the
> > flush_delayed_fput() call in init/main.c.
> 
> My initial version of the patch did not remove the call to
> flush_delayed_fput() from init/main.c but Al Viro asked to drop it as it
> is called in populate_rootfs().
> 
> May be Al Viro can give more data on what is happening here.

Thanks,  any comments or history lessons would be good here.

-Stafford