linux-kernel - Re: [PATCH] iov_iter: separate direction from flavour

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:   Sun, 4 Jul 2021 13:28:44 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Christoph Hellwig <hch@....de>, Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        David Sterba <dsterba@...e.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Anton Altaparmakov <anton@...era.com>,
        David Howells <dhowells@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Pavel Begunkov <asml.silence@...il.com>
Subject: Re: [PATCH] iov_iter: separate direction from flavour

On 7/4/21 12:04 PM, Linus Torvalds wrote:
> On Sun, Jul 4, 2021 at 11:54 AM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> No, I still see the same warning, with the same traceback. I did make sure
>> that the code is executed by adding a printk in front of it.
> 
> And that printk() hits before the WARN_ON_ONCE() hits?
> 

Yes:

[    8.604785] Run /init as init process
[    8.604933] ##################### calling force_uaccess_begin()
[    8.609691] ------------[ cut here ]------------
[    8.609795] WARNING: CPU: 0 PID: 1 at lib/iov_iter.c:468 iov_iter_init+0x35/0x58
[    8.609979] CPU: 0 PID: 1 Comm: init Not tainted 5.13.0-09608-g678b12cd4025-dirty #1

Either case, the code doesn't do anything, because force_uaccess_begin() is
already called. With more added debugging:

##################### calling force_uaccess_begin()
############## force_uaccess_begin(), called from run_init_process+0x80/0x8c
############## force_uaccess_begin(), called from load_flat_binary+0x10e/0x92a

> Funky. That sounds to me like something is then doing
> set_fs(KERNEL_DS) again later, but it's also possible that I've been
> dropped on my head a few too many times as a young child, and am
> missing something completely obvious.
> 
> Can somebody put me out of my misery and say "Oh, Linus, please take
> your meds - you're missing xyz..."
> 

Turns out that, at least on m68k/nommu, USER_DS and KERNEL_DS are the same.

#define USER_DS         MAKE_MM_SEG(TASK_SIZE)
#define KERNEL_DS       MAKE_MM_SEG(0xFFFFFFFF)

and:

#define TASK_SIZE       (0xFFFFFFFFUL)

I didn't check mps2, but I strongly suspect the same is true there.

Guenter