linux-kernel - Re: Possible "struct pid" leak from tty

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: <m1y7m64cpw.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 09 Mar 2007 09:13:15 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Catalin Marinas" <catalin.marinas@...il.com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: Possible "struct pid" leak from tty_io.c

"Catalin Marinas" <catalin.marinas@...il.com> writes:

> On 08/03/07, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> "Catalin Marinas" <catalin.marinas@...il.com> writes:
>
> I think it's only the pid_chain and rcu member that could be placed in
> a list and kmemleak scans the memory for these two offsets as well.
> I'll check those lists anyway but I doubt it's a more fundamental
> problem with how kmemleak handles struct pid as I should've probably
> got more reports.

Right.  I was pointing out the possibilities but because we do
some tricky things.  Mostly I was wondering about the hlist for
the list of tasks.  Now if a task is on that list we should have
a struct pid_link pointing at our struct pid, so it shouldn't fool
kmemleak but I'm still a little curious if all of those hlist_heads are
NULL pointers.

>> In most any other layer we cache pids indefinitely and a situation
>> where we have a pointer to a struct pid with a ref count of 1 long
>> after the process goes away is expected.
>
> Yes, indeed, but what kmemleak reports is that the pid structure
> wasn't freed yet and there is no way to determine its pointer directly
> or via container_of on members (by scanning the memory), hence it is
> considered a leak.

Yes that sounds like a leak.

>> I don't understand your situation enough to guess what is going wrong
>> yet.  Hopefully I have given you enough information to get started.
>
> Yes, many thanks. I'll dig further and let you know.

Thanks....

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