linux-kernel - Re: Make sure we populate the initroot filesystem late enough

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:	Sun, 25 Feb 2007 19:45:50 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Woodhouse <dwmw2@...radead.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linuxppc-dev@...abs.org, john stultz <johnstul@...ibm.com>
Subject: Re: Make sure we populate the initroot filesystem late enough

On Sun, 25 Feb 2007, David Woodhouse wrote:
> 
> I'm inclined to agree that it _shouldn't_ be a problem. Nevertheless,
> even this hack seems sufficient to 'fix' it:

Ok. Clearly something is using that memory. That said, I *suspect* that 
the commit that you bisected to is just showing the problem indirectly. 
The ordering shouldn't make any difference, but it can obviously make a 
huge difference in various allocation patterns etc, thus just showing a 
pre-existing problem more clearly..

Can you try adding something like

	memset(start, 0xf0, end - start);

to before the return? That might give a better idea of exactly what is 
using it after it's free'd, hopefully by having the user trigger some more 
spectacular oops..

It is, of course, also entirely possible that the rootfs unpacking change 
really *was* buggy, and I am just missing something totally obvious. The 
memset() might still make it more obvious, though. Maybe.

>         if (start < end)
> -               printk ("Freeing initrd memory: %ldk freed\n", (end - start) >> 10);
> +               printk ("NOT Freeing initrd memory: %ldKiB would be freed\n", (end - start) >> 10);

.. so adding the "memset()" here would be what I'm suggesting ..

> +       return;

.. and you might as well leave the return there, so that nobody else comes 
along and re-uses the memory. That should just improve on the chances of 
the memset() hopefully catching the problem..

		Linus "I don't see anything wrong" Torvalds
-
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/