linux-kernel - Re: [PATCH] module: always complete idempotent loads

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: <CAHk-=wg70vQAKPOqo-Ym6n47KSpm09kc-dmKME9Sd1HUcdZ-sg@mail.gmail.com>
Date:   Tue, 4 Jul 2023 10:10:14 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Vegard Nossum <vegard.nossum@...cle.com>
Cc:     Luis Chamberlain <mcgrof@...nel.org>,
        George Kennedy <george.kennedy@...cle.com>,
        linux-kernel@...r.kernel.org, linux-modules@...r.kernel.org,
        Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
        syzbot+9c2bdc9d24e4a7abe741@...kaller.appspotmail.com,
        Johan Hovold <johan@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Rudi Heitbaum <rudi@...tbaum.com>,
        David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH] module: always complete idempotent loads

On Tue, 4 Jul 2023 at 08:12, Vegard Nossum <vegard.nossum@...cle.com> wrote:
>
> Maybe just do the f_mode check in finit_module()? Or... new helper,
> fdget_mode()??

I actually wanted to do a fdget_read/write() helper long ago: we
already basically pass in a "this mode is not ok" flag for the
FMODE_PATH case, and it's sad how many extra "do we have
FMODE_READ/WRITE" tests we have when it would actually make tons of
sense to just check it at fdget() time.

But I created the patch, and then decided it was just churn for
something that didn't matter a lot.

The existing "mode" argument to __fget_light() and __fget() would end
up split into "error if these bits are set" (existing) and "error if
these bits are _not_ set" (new) arguments.

It was straightforward, but I looked at the patch, and then looked at
all the existing users that currently check the error separately, and
went "bah", and threw it all away.

Which is not to say it's not the right thing to do. Maybe we should at
some point. But doing it right (ie doing it in that helper before we
even bother with reference counting etc) is just a bit too much work.

The alternative is, of course, to just have a *truly* stupid wrapper
that does the error checking and does the "fdput()" if FMODE_READ
wasn't set. But that's just disgusting.

Anyway, for this module case, I just moved it out to the caller.

> Apart from this, there is another bit that looks a bit weird:
>
> len = kernel_read_file(f, 0, &buf, INT_MAX, NULL, READING_MODULE);
> if (len < 0) {
>      mod_stat_inc(&failed_kreads);
>      mod_stat_add_long(len, &invalid_kread_bytes);
>
> I don't think we should be adding error codes to byte counts.

Ack. I fixed that at the same time as a "multiple problems with the
error paths".

                 Linus