linux-kernel - Re: linux-next: Tree for Sep 12 (bcachefs)

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: <20230919212318.6kr772hz3m5dsyck@moria.home.lan>
Date:   Tue, 19 Sep 2023 17:23:18 -0400
From:   Kent Overstreet <kent.overstreet@...ux.dev>
To:     Kees Cook <keescook@...omium.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-hardening@...r.kernel.org
Subject: Re: linux-next: Tree for Sep 12 (bcachefs)

On Thu, Sep 14, 2023 at 05:20:41PM -0700, Kees Cook wrote:
> Because they're ambiguous and then the compiler can't do appropriate
> bounds checking, compile-time diagnostics, etc. Maybe it's actually zero
> sized, maybe it's not. Nothing stops them from being in the middle of
> the structure so if someone accidentally tries to put members after it
> (which has happened before), we end up with bizarre corruptions, etc,
> etc. Flexible arrays are unambiguous, and that's why we committed to
> converting all the fake flex arrays. The compiler does not have to guess
> (or as has been the case: give up on) figuring out what was intended.

So it does seem like we need to be able to distinguish between normal
flex arrays that go at the end of a struct vs. - what should we call
them, markers? that go in the middle.

> Regardless, I'm just trying to help make sure folks that run with
> CONFIG_UBSAN_BOUNDS=y (as done in Android, Ubuntu, etc) will be able to
> use bcachefs without runtime warnings, etc. Indexing through a 0-sized
> array is going to trip the diagnostic either at runtime or when building
> with -Warray-bounds.

I do have CONFIG_UBSAN_BOUNDS=y testing in my own CI, so all the runtime
errors should be fixed now (some of them with casts, but the casts are
in helpers that know what they're doing, not scattered around at
random).

So I think we're good for now - I'm going to hold off on more cleanup
for now unless reports of actual ubsan splats turn up, since I'm getting
a bit bombarded at the moment :)