linux-kernel - Re: [PATCH] early init: open /dev/console with O

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, 2 Jan 2020 11:09:48 +0800
From:   youling 257 <youling257@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Arvind Sankar <nivedita@...m.mit.edu>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] early init: open /dev/console with O_LARGEFILE

2020-01-02 5:39 GMT+08:00, Linus Torvalds <torvalds@...ux-foundation.org>:
> On Wed, Jan 1, 2020 at 10:32 AM Arvind Sankar <nivedita@...m.mit.edu>
> wrote:
>>
>> Also, this shouldn't impact the current issue I think, but won't doing
>> filp_open followed by 3 f_dupfd's cause the file->f_count to become 4
>> but with only 3 open fd's? Don't we have to do an fd_install for the
>> first one and only 2 f_dupfd's?
>
> I think *this* is the real reason for the odd regression.
>
> Because we're leaking a file count, the original /dev/console stays
> open, and we end up never calling file->f_op->release().
>
> So we don't call tty_release() on that original /dev/console open, and
> one effect of that is that we never then call session_clear_tty(),
> which should make sure that all the processes in that session ID have
> their controlling tty (signal->tty pointer) cleared.
>
> And if that original controlling tty wasn't cleared, then subsequent
> calls to set the controlling tty won't do anything, and who knows what
> odd session leader confusion we might have.
>
> youling, can you check if - instead of the revert - this simple 'add
> an fput' fixes your warning.
>
> I'm not saying that the revert is wrong at this point, but honestly,
> I'd like to avoid the "we revert because we didn't understand what
> went wrong". It would be good to go "Aaaahhhh, _that_ was the
> problem".
>
>                  Linus
>

test this patch.diff, no the system/bin/sh warning, fixed.