On Fri, Apr 14, 2023 at 04:46:31PM +0100, Al Viro wrote:
> On Fri, Apr 14, 2023 at 04:24:55PM +0100, Luca Vizzarro wrote:
> > void __user *argp = (void __user *)arg;
> > + int argi = (int)arg;
>
> Strictly speaking, conversion from unsigned long to int is
> an undefined behaviour, unless the value fits into the
> range representable by int ;-)
>
> > case F_SETFD:
> > err = 0;
> > - set_close_on_exec(fd, arg & FD_CLOEXEC);
> > + set_close_on_exec(fd, argi & FD_CLOEXEC);
>
> Why?
>
> > case F_SETSIG:
> > /* arg == 0 restores default behaviour. */
> > - if (!valid_signal(arg)) {
> > + if (!valid_signal(argi)) {
>
> Why???
>
> > break;
> > }
> > err = 0;
> > - filp->f_owner.signum = arg;
> > + filp->f_owner.signum = argi;
> > break;
>
> These two are clearly bogus and I'd like to see more details
> on the series rationale, please.
I agree the first isn't necessary, but I don't think the second is bogus, since
valid_signal() takes an unsigned long and the man page for F_SETSIG says that
the argument is an int:
https://man7.org/linux/man-pages/man2/fcntl.2.html
... though arguably that could be a bug in the man page.
The cover letter really should have quoted the description that Szabolcs wote
at:
https://lore.kernel.org/linux-api/Y1%2FDS6uoWP7OSkmd@xxxxxxx/
The gist being that where the calling convention leaves narrowing to callees
(as is the case on arm64 with our "AAPCS64" calling convention), if the caller
passes a type which is narrower than a register, the upper bits of that
register may contain junk.
So e.g. for F_SETSIG, if the userspace will try to pass some 32-bit value,
leaving bits 63:32 of the argument register containing arbitrary junk. Then
here we interprert the value as an unsigned long, considering that junk as part
of the argument. Then valid_signal(arg) may end up rejecting the argument due
to the junk uper bits, which is surprising to the caller as from its PoV it
passed a 32-bit value in the correct way.
So either:
* That's a documentation bug, and userspce needs to treat the agument to
F_SETSIG as an unsigned long.
* The kernel needs to narrow the argument to an int (if required by the calling
convention) to prevent that.
Does that make sense, or have I missed the point you were making?
Thanks,
Mark.
