linux-kernel - Re: + redo-locking-of-tty-pgrp.patch added to -mm tree

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-next>] [day] [month] [year] [list]

Message-ID: <20080223171746.GB7686@tv-sign.ru>
Date:	Sat, 23 Feb 2008 20:17:46 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	akpm@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, alan@...rguk.ukuu.org.uk,
	alan@...hat.com
Subject: Re: + redo-locking-of-tty-pgrp.patch added to -mm tree

On 02/22, Andrew Morton wrote:
> 
> Subject: redo locking of tty->pgrp
> From: Alan Cox <alan@...rguk.ukuu.org.uk>
> 
> Historically tty->pgrp and friends were pid_t and the code "knew" they were
> safe.  The change to pid structs opened up a few races and the removal of the
> BKL in places made them quite hittable.  We put tty->pgrp under the ctrl_lock
> for the tty.

tiocgpgrp() still does pid_vnr(real_tty->pgrp) lockless, this is not safe, no?
(the same for do_task_stat).

It can race with tiocspgrp()->put_pid(real_tty->pgrp) which can actually free
that pid. If this memory is reused, pid_nr_ns() can (in theory) crash.

Oleg.

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