[<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