linux-kernel - Re: possible deadlock in console

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:   Thu, 7 Jun 2018 23:03:19 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        syzbot <syzbot+43e93968b964e369db0b@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, rostedt@...dmis.org,
        sergey.senozhatsky@...il.com, syzkaller-bugs@...glegroups.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, linux-serial@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: possible deadlock in console_unlock

On (06/07/18 20:40), Tetsuo Handa wrote:
> >> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> >> index c996b6859c5e..71958ef6a831 100644
> >> --- a/drivers/tty/tty_buffer.c
> >> +++ b/drivers/tty/tty_buffer.c
> >> @@ -167,7 +167,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
> >>  	   have queued and recycle that ? */
> >>  	if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
> >>  		return NULL;
> >> -	p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> >> +	p = kmalloc(sizeof(struct tty_buffer) + 2 * size,
> >> +			GFP_ATOMIC | __GFP_NOWARN);
> >>  	if (p == NULL)
> >>  		return NULL;
> >>
> >> ---
> > 
> > This looks like the most simple solution for this particular problem.
> > I am just afraid that there are many other locations like this.
> > 
> I haven't tried the reproducer with that change. But isn't __GFP_NOWARN
> ignored by fail_dump() (and thus printk() from fault injection still occurs)?

Thanks for the info. Need to check it [I didn't know that GFP_NOWARN
meant GFP_WARN_ME_SOMETIMES]. If this is the case then we have just one
option left - printk_safe contexts for TTY/UART locks.

	-ss