linux-kernel - Re: Weird kernel 2.6.17.[67] behaviour

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: <20060727100727.GA8408@frankengul.org>
Date:	Thu, 27 Jul 2006 12:07:27 +0200
From:	seb@...nkengul.org
To:	Adam Henley <adamazing@...il.com>
Cc:	debian-sparc@...ts.debian.org, linux-kernel@...r.kernel.org
Subject: Re: Weird kernel 2.6.17.[67] behaviour

On Thu, Jul 27, 2006 at 12:41:56AM +0100, Adam Henley wrote:
> On 27/07/06, Sébastien Bernard <seb@...nkengul.org> wrote:
> >seb@...nkengul.org a écrit :
> >> I got a perfectly workable kernel 2.6.17.1 using mkinitramfs on my U60.
> >>
> >> Can you shed some lights on this dark corner of linux ?
> >>
> >>       Seb
> 
> I can't shed any more light on it, but I can look too :o)

:). It was just a poetic licence.

> 
> The original mailing of the patch to the list is below:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0607.1/1694.html
> 
> [snip>
> The prctl() system call should never allow to set "dumpable" to the
> value 2. Especially not for non-privileged users.
> 
> This can be split into three cases:
>  1) running as root -- then core dumps will already be done as root,
>     and so prctl(PR_SET_DUMPABLE, 2) is not useful
>  2) running as non-root w/setuid-to-root -- this is the debatable case
>  3) running as non-root w/setuid-to-non-root -- then you definitely
>     do NOT want "dumpable" to get set to 2 because you have the
>     privilege escalation vulnerability
> <snip]
> 
> Is it that something else is misbehaving and trying to dump core as root?
> 

Well, I'm not arguing that the fix is a wrong fix.

I'm seeing that, on sparc64-smp arch with debian etch, this patch causes
a very strange sideeffect I was describing in my first mail.

The boot hangs, the cursor (in the framebuffer) stops blinking, nothing
is displayed, and the machine seems frozen until I hit a key or a button
mouse (which is on sparc causing the same interruption), and then the
machine resume the boot sequence as if nothing really happened.

I've been able to isolate that line to be the origin of this behaviour
but it could be as well a bug revealed by this modification.

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