linux-kernel - Re: tty_io.c - disassociate_ctty attempted to write to tty = NULL question/problem?

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: <20100105001205.7e8f131b@lxorguk.ukuu.org.uk>
Date:	Tue, 5 Jan 2010 00:12:05 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Michael Breuer <mbreuer@...jas.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: tty_io.c  - disassociate_ctty attempted to write to tty = NULL
 question/problem?

> do_exit -> disassocate_ctty(1) (for tty1).
> disassociate->vhangup->do_tty_hangup
> 
> In do_tty_hangup, p->signal->tty is set to NULL, where p==current.

Perfectly reasonable so far - the current process gave up having a
controlling tty.

> On return, the aforementioned error message is generated.

>From where - the backtrace on the write to NULL tty is the important bit
here. User space interfaces cache tty in filp->private_data so its not
going to be coming from there unless there was a memory scribble which
would imply a refcounting bug - and I'd expect people to hit that
reliably.

Some kernel stuff does take a peek at p->signal->tty for direct printk
type stuff and that sounds more likely - the backtraceon the write to
NULL tty is going to provide the needed info.

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