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-=whrbqBn_rCnPNwtLuoGHwjkqsLgDXYgjA0NW2ShAwqNkw@mail.gmail.com>
Date: Fri, 18 Jul 2025 15:48:44 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Eugenio Pérez <eperezma@...hat.com>, 
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	"Michael S. Tsirkin" <mst@...hat.com>, Al Viro <viro@...iv.linux.org.uk>, 
	Alexei Starovoitov <ast@...nel.org>, Alexey Dobriyan <adobriyan@...il.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Andrii Nakryiko <andrii@...nel.org>, 
	Arnd Bergmann <arnd@...nel.org>, Borislav Petkov <bp@...en8.de>, Cong Wang <cong.wang@...edance.com>, 
	Dan Williams <dan.j.williams@...el.com>, Daniel Borkmann <daniel@...earbox.net>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, David Laight <David.Laight@...lab.com>, 
	David Lechner <dlechner@...libre.com>, Dinh Nguyen <dinguyen@...nel.org>, 
	Eduard Zingerman <eddyz87@...il.com>, Gatlin Newhouse <gatlin.newhouse@...il.com>, 
	Hao Luo <haoluo@...gle.com>, Ingo Molnar <mingo@...hat.com>, 
	Jakub Sitnicki <jakub@...udflare.com>, Jan Hendrik Farr <kernel@...rr.cc>, Jason Wang <jasowang@...hat.com>, 
	Jiri Olsa <jolsa@...nel.org>, John Fastabend <john.fastabend@...il.com>, 
	Jonathan Cameron <Jonathan.Cameron@...wei.com>, Josh Poimboeuf <jpoimboe@...nel.org>, 
	KP Singh <kpsingh@...nel.org>, Kees Cook <kees@...nel.org>, 
	Luc Van Oostenryck <luc.vanoostenryck@...il.com>, Marc Herbert <Marc.Herbert@...ux.intel.com>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Mateusz Guzik <mjguzik@...il.com>, Michal Luczaj <mhal@...x.co>, 
	Miguel Ojeda <ojeda@...nel.org>, Mykola Lysenko <mykolal@...com>, NeilBrown <neil@...wn.name>, 
	Peter Zijlstra <peterz@...radead.org>, Przemek Kitszel <przemyslaw.kitszel@...el.com>, 
	Sami Tolvanen <samitolvanen@...gle.com>, Shuah Khan <shuah@...nel.org>, Song Liu <song@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Thomas Gleixner <tglx@...utronix.de>, 
	Thorsten Blum <thorsten.blum@...ux.dev>, Uros Bizjak <ubizjak@...il.com>, 
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Yafang Shao <laoar.shao@...il.com>, 
	Ye Bin <yebin10@...wei.com>, Yonghong Song <yonghong.song@...ux.dev>, 
	Yufeng Wang <wangyufeng@...inos.cn>, bpf@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-sparse@...r.kernel.org, virtualization@...ts.linux.dev, x86@...nel.org
Subject: Re: [PATCH 4/7] arch/nios: replace "__auto_type" with "auto"

On Fri, 18 Jul 2025 at 14:49, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Fri, 18 Jul 2025 at 14:34, H. Peter Anvin <hpa@...or.com> wrote:
> >
> > -       __auto_type __pu_ptr = (ptr);                                   \
> > +       auto __pu_ptr = (ptr);                                  \
> >         typeof(*__pu_ptr) __pu_val = (typeof(*__pu_ptr))(x);            \
>
> But that second case obviously is exactly the "auto type" case, just
> written using __typeof__.

Actually, looking at it, I actually think the NIOS2 header is a bit
buggy here, exactly because it should *not* have that cast to force
the types the same.

It's the exact same situation that on x86 is inside
do_put_user_call(), and on x86 uses that

        __typeof__(*(ptr)) __x = (x); /* eval x once */

pattern instead: we don't want a cast, because we actually want just
the implicit type conversions, and a warning if the types aren't
compatible. Writing things to user space is still supposed to catch
type safety issues.

So having that '(typeof(*__pu_ptr))' cast of the value of '(x)' is
actually wrong, because it will silently (for example) convert a
pointer into a 'unsigned long' or vice versa, and __put_user() just
shouldn't do that.

If the user access is to a 'unsigned long __user *' location, the
kernel shouldn't be writing pointers into it.

Do we care? No. This is obviously nios2-specific, and the x86 version
will catch any generic mis-uses where somebody would try to
'put_user()' the wrong type.

And any "auto" conversion wouldn't change the bug anyway. But I
thought I'd mention it since it started bothering me and I went and
looked closer at that case I quoted.

And while looking at this, I think we have a similar mis-feature / bug
on x86 too: the unsafe_put_user() macro does exactly that cast:

  #define unsafe_put_user(x, ptr, label)  \
        __put_user_size((__typeof__(*(ptr)))(x), ..

and I think that cast is wrong.

I wonder if it's actively hiding some issue with unsafe_put_user(), or
if I'm just missing something.

            Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ