Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 17 Apr 2023 10:38:22 +0100
From:   Mark Rutland <mark.rutland@arm.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Luca Vizzarro <Luca.Vizzarro@arm.com>,
        linux-kernel@vger.kernel.org,
        Christian Brauner <brauner@kernel.org>,
        Jeff Layton <jlayton@kernel.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        Kevin Brodsky <Kevin.Brodsky@arm.com>,
        Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
        Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
        Theodore Ts'o <tytso@mit.edu>,
        David Laight <David.Laight@aculab.com>,
        linux-fsdevel@vger.kernel.org, linux-morello@op-lists.linaro.org
Subject: Re: [PATCH v2 1/5] fcntl: Cast commands with int args explicitly
Message-ID: <ZD0Tjk2oO8Ewj1nc@FVFF77S0Q05N>
References: <20230414152459.816046-1-Luca.Vizzarro@arm.com>
 <20230414152459.816046-2-Luca.Vizzarro@arm.com>
 <20230414154631.GK3390869@ZenIV>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230414154631.GK3390869@ZenIV>
Precedence: bulk

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@arm.com/

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.