linux-kernel - Re: [PATCH] vfs: fix statfs64() returning impossible EOVERFLOW for 64-bit f

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, 5 Oct 2017 18:31:29 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Sergey Klyaus <sergey.m.klyaus@...il.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Li Wang <liwang@...hat.com>,
        Andreas Dilger <adilger@...ger.ca>,
        Andi Kleen <andi.kleen@...el.com>
Subject: Re: [PATCH] vfs: fix statfs64() returning impossible EOVERFLOW for
 64-bit f_files

On Thu, Oct 5, 2017 at 4:06 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Just to make sure we are on the same page: out of kstatfs fields
> we have 5 u64 ones (see above; all of them are u64 is struct statfs64
> on all architectures), an opaque 64bit f_fsid and 5 fields that
> are long: f_type (magic numbers, all 32bit), f_namelen (max filename
> length), f_frsize (0 on most of filesystems, always fits into 32 bits),
> f_flags (guaranteed to be 32bit) and f_bsize.

Please just use that FITS_IN() kind of macro regardless.

If the sizes match, the compiler will optimize the test away.

If the sizes don't match, that FITS_IN() will do the right thing.

Do *not* manually go and say "these fields are ok, because..". The
whole bug was because people were confused about the field widths.

                 Linus