On Tue, 4 Feb 2025 at 13:51, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > Pidfs supports extensible and non-extensible ioctls. The extensible > ioctls need to check for the ioctl number itself not just the ioctl > command otherwise both backward- and forward compatibility are broken. > > The pidfs ioctl handler also needs to look at the type of the ioctl > command to guard against cases where "[...] a daemon receives some > random file descriptor from a (potentially less privileged) client and > expects the FD to be of some specific type, it might call ioctl() on > this FD with some type-specific command and expect the call to fail if > the FD is of the wrong type; but due to the missing type check, the > kernel instead performs some action that userspace didn't expect." > (cf. [1]] > > Reported-by: Jann Horn <jannh@xxxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx # v6.13 > Fixes: https://lore.kernel.org/r/CAG48ez2K9A5GwtgqO31u9ZL292we8ZwAA=TJwwEv7wRuJ3j4Lw@xxxxxxxxxxxxxx [1] > Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx> > --- > Hey, > > Jann reported that the pidfs extensible ioctl checking has two issues: > > (1) We check for the ioctl command, not the number breaking forward and > backward compatibility. > > (2) We don't verify the type encoded in the ioctl to guard against > ioctl number collisions. > > This adresses both. > > Greg, when this patch (or a version thereof) lands upstream then it > needs to please be backported to v6.13 together with the already > upstream commit 8ce352818820 ("pidfs: check for valid ioctl commands"). > > Christian Thanks for the fixes, LGTM Acked-by: Luca Boccassi <luca.boccassi@xxxxxxxxx>
