linux-kernel - Re: 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit

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: <20100215065629.GA14412@jm.kir.nu>
Date:	Mon, 15 Feb 2010 08:56:29 +0200
From:	Jouni Malinen <j@...fi>
To:	Michael Neuling <mikey@...ling.org>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.33-rc8 breaks UML with Restrict initial stack space
 expansion to rlimit

On Mon, Feb 15, 2010 at 09:03:39AM +1100, Michael Neuling wrote:
> Crud, the "killed" is definitely something this patch could cause.
> 
> I'm not familiar with UML.  Is this the guest and the host booting rc8,
> or just the host?  Does UML use stack protection at all?

Only the guest was booting rc8 (host is Ubuntu 2.6.31-19-generic), i.e.,
the issue shows up in the guest kernel after rc8 (and is removed by
reverting 803bf5). I do not know whether stack protection is used.

> Can you try booting the guest to init=/bin/sh and try running some tests
> to see what you can set 'ulimit -s' to and still be able to run a simple
> command like '/bin/ls'?

With 803bf5 included, init=/bin/sh seems to fail the boot quite
frequently, but not always. Once I get to shell on the UML guest,
/bin/ls fails about half of the time (e.g., running /bin/ls in /root
failed six times out of ten). This was before touching ulimit -s at all
("ulimit -s" shows 8192).

The behavior of 'ls' run with various ulimit -s values:

24-10000: OK or Killed
16-23: OK or Segmentation fault or Killed
1-15: Killed or Segmentation fault

I have no idea what is causing the random behavior in the results, but
anyway, it looks like 'ulimit -s 23' is the first point where
segmentation faults start showing up and 'ulimit -s 15' is the point
where ls fails every time.

If I start the guest (normal boot with multiple virtual consoles) with
803bf5 reverted, 'ulimit -s 84' has /bin/ls working every time and
'ulimit -s 83' makes it fail every time.

-- 
Jouni Malinen                                            PGP id EFC895FA
--
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/