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: <20130922200354.GA4865@redhat.com>
Date:	Sun, 22 Sep 2013 22:03:54 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	codonell <codonell@...hat.com>, Eduard Benes <ebenes@...hat.com>,
	Karel Srot <ksrot@...hat.com>,
	Matt Newsome <mnewsome@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] tty: disassociate_ctty() sends the extra SIGCONT

On 09/21, Peter Hurley wrote:
>
> On 09/21/2013 02:34 PM, Oleg Nesterov wrote:
>>
>> 		do_each_pid_task(tty->session, PIDTYPE_SID, p) {
>> 			spin_lock_irq(&p->sighand->siglock);
>> 			if (p->signal->tty == tty) {
>> 				p->signal->tty = NULL;
>> 				/* We defer the dereferences outside fo
>> 				   the tasklist lock */
>> 				refs++;
>> 			}
>> 			if (!p->signal->leader) {
>> 				spin_unlock_irq(&p->sighand->siglock);
>> 				continue;
>> 			}
>> 			__group_send_sig_info(SIGHUP, SEND_SIG_PRIV, p);
>> 			__group_send_sig_info(SIGCONT, SEND_SIG_PRIV, p);
>> 			put_pid(p->signal->tty_old_pgrp);  /* A noop */
>> 			spin_lock(&tty->ctrl_lock);
>> 			tty_pgrp = get_pid(tty->pgrp);
>>
>> I guess this can happen only once, so we could even add WARN_ON(tty_pgrp)
>> before get_pid(). But this look confusing, as if we can do get_pid()
>> multiple times and leak tty->pgrp.
>>
>> 			if (tty->pgrp)
>> 				p->signal->tty_old_pgrp = get_pid(tty->pgrp);
>>
>> else? We already did put_pid(tty_old_pgrp), we should clear it.
>>
>> IOW, do you think the patch below makes sense or I missed something?
>> Just curious.
>
> The code block you're referring to only executes once because there is
> only one session leader.

I understand, and I even mentioned this above.

My point was, this _looks_ confusing, and the patch I sent makes it
more clean.

And what about ->tty_old_pgrp? I still think that at least the patch
below makes sense. If tty->pgrp == NULL is not possible here (I do
not know), then why do we check? Otherwise ->tty_old_pgrp != NULL looks
certainly wrong after put_pid().

Oleg.

--- x/drivers/tty/tty_io.c
+++ x/drivers/tty/tty_io.c
@@ -569,8 +569,7 @@ static int tty_signal_session_leader(str
 			put_pid(p->signal->tty_old_pgrp);  /* A noop */
 			spin_lock(&tty->ctrl_lock);
 			tty_pgrp = get_pid(tty->pgrp);
-			if (tty->pgrp)
-				p->signal->tty_old_pgrp = get_pid(tty->pgrp);
+			p->signal->tty_old_pgrp = get_pid(tty->pgrp);
 			spin_unlock(&tty->ctrl_lock);
 			spin_unlock_irq(&p->sighand->siglock);
 		} while_each_pid_task(tty->session, PIDTYPE_SID, p);

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ