linux-kernel - Re: WARNING at: drivers/char/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]

Date:	Mon, 3 Aug 2009 17:59:09 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...l.by>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: WARNING at: drivers/char/tty_ldisc.c

> it. But, even before the patch, it seems we didn't
> 
> 	filp->f_op = &hung_up_tty_fops;
> 
> for console stuff. But, I'm still not found why we avoid to the above...

Not sure - I'd have to re-read all the specs. Could be that applications
writing to the console do not expect to get a hangup when the device for
the console ceases to be a controlling terminal. That would be a
behaviour change. Equally if we don't set the hung_up file operations we
can't call ->hangup().

I'd be very concerned about having the console behaviour changed. For a
late -rc I'd think it may even be better to leak an ldisc instance in
that case providing end users can't cause a repeated leak of that form.

(ie if its got a use count when we got to free it we just look the other
way or queue the kfree)

The more I look at this the more risky all the changes look except for
switching it to refcount properly.

We risk changing the behaviour of consoles in ways that might break apps
and certainly break our behaviour. We end up risking messing up serial
consoles and trying to printk to down devices.

Proper refcounting on the other hand fixes the real problem in a
controlled fashion without hard to analyse and define behaviour changes.

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/