linux-kernel - Re: [BUG] Linux 2.6.25.4 task

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: <484719C7.2020502@thorsten-knabe.de>
Date:	Thu, 05 Jun 2008 00:40:07 +0200
From:	Thorsten Knabe <linux@...rsten-knabe.de>
To:	Jeff Dike <jdike@...toit.com>
CC:	Chris Wright <chrisw@...s-sol.org>, linux-kernel@...r.kernel.org
Subject: Re: [BUG] Linux 2.6.25.4 task_struct leak

Jeff Dike wrote:
> On Sun, Jun 01, 2008 at 02:31:39PM -0700, Chris Wright wrote:
>> * Thorsten Knabe (linux@...rsten-knabe.de) wrote:
>>> [5.] Most recent kernel version which did not have the bug:
>>> 2.6.23.17 does not leak task_structs.
>>> 2.6.24 - 2.6.25.3 has not been tested
> 
> Has this been seen on non-UML?

Hello Jeff.

I'm not sure, if I understood your question correctly. The task_struct
leak is on the host running a vanilla Linux 2.6.25.4 x86_64 on real
hardware and not within the UML instances. I'll try to describe the
situation more precisely:

The host system is a vanilla Linux 2.6.25.4 x86_64 running on real
hardware with a Debian Etch x86_64 user space. However I've created a
Debian Etch i386 (32bit) userspace chroot environment on the system,
which is used, among other things, to compile the Linux 2.6.23.17 UML
kernels and start various UML instances.

I can start other 32-bit applications, for example compile an UML
kernel, within the chroot without leaking task_structs, but as soon as I
start an UML instance, I see leaked task_structs. Starting and
immediately shutting down an UML instacne leaks approximately 2000
task_structs. The number of leaked task_structs on the host seems to be
equal to the number of processes that have been created (and destroyed)
within the UML instances.

The host system was upgraded from 2.6.23.17 x86_64 which did not leak
task_structs to 2.6.25.4 x86_64. Also running the same UML kernels and
filesystems on my laptop with a vanilla Linux 2.6.25.4 i386 kernel does
not leak task_structs. The version of the UML kernel (tested 2.6.23.17
and 2.6.25.4) does not seem to matter.

As far as I understand the UML code in the kernel, an UML kernel uses
some unusual clone() flags when creating new processes, which are seldom
used by other applications and could be related to the bug.

If there is no obvious bug in the code, I'll try to bisect that beast
next weekend as suggested by Chris.

Regards
Thorsten

-- 
___
 |        | /                 E-Mail: linux@...rsten-knabe.de
 |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de
--
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/