linux-hardening - Re: [REGRESSION][BISECTED] erroneous buffer overflow detected in bch2_xattr

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72=yYDcG=ef9TxCCECwjSgW-5zFoTJqcjrWGOALCvaW0SA@mail.gmail.com>
Date: Mon, 21 Oct 2024 08:04:03 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Jan Hendrik Farr <kernel@...rr.cc>
Cc: Nathan Chancellor <nathan@...nel.org>, Bill Wendling <morbo@...gle.com>, Kees Cook <kees@...nel.org>, 
	Thorsten Blum <thorsten.blum@...lux.com>, kent.overstreet@...ux.dev, 
	regressions@...ts.linux.dev, linux-bcachefs@...r.kernel.org, 
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org, 
	ardb@...nel.org, ojeda@...nel.org
Subject: Re: [REGRESSION][BISECTED] erroneous buffer overflow detected in bch2_xattr_validate

On Mon, Oct 21, 2024 at 3:33 AM Jan Hendrik Farr <kernel@...rr.cc> wrote:
>
> I think I prefer
>
>         depends on !(CC_IS_CLANG && CLANG_VERSION < 190103)
>
> to make it more clear that the purpose is to disable this for clang
> versions below 19.1.3, but keep it enabled for every other compiler
> including pre-release gcc versions that pass the compile test.

Do we want other tooling to see the attribute? i.e. if the build check
gets removed, then that `depends on` would mean other tooling would
see it, right?

> Also after gcc 15 is released I don't think a version check for gcc
> should be necessary. I only see an explicit version check as required
> when we know a certain version is broken. Otherwise I would prefer using
> the build test.

Yeah, build tests are nice, although they require spawning a process
and so on, which (as far as I understand) we try to minimize. Version
checks also have the advantage that it is easy to remember/check when
we can remove the checks themselves when we upgrade the minimum
versions.

> I guess an alternative would be to just create a
> CC_COUNTED_BY_BROKEN that is enabled for clang versions below 19.1.3
> and continue to use __has_attribute together with that option. That
> would make the build test unnecesarry. The downside is that it
> will require checking both __has_attribute and
> CONFIG_CC_COUNTED_BY_BROKEN for __counted_by support. So I think
> CC_HAS_COUNTED_BY is better.

Yeah, if we are going to need a new Kconfig symbol anyway, then let's
make that the only thing to check. Otherwise we are in the "worst of
both worlds", I would say.

> I'll submit it once Bill's fix is in the release/19.x branch. Which
> maintainer should I address this too? You (Nathan), Miguel, Kees, or
> someone else?

Sounds good -- if you want, you can send it to all of us and we can
figure that out later.

Thanks!

Cheers,
Miguel