On Fri, 2017-06-16 at 12:13 +1000, NeilBrown wrote: > On Thu, Jun 15 2017, Andrew Morton wrote: > > > On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown <neilb@xxxxxxxx> wrote: > > > > > > > > If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL > > > ioctl, autofs4_d_automount() will return > > > ERR_PTR(status) > > > with that status to follow_automount(), which will then > > > dereference an invalid pointer. > > > > > > So treat a positive status the same as zero, and map > > > to ENOENT. > > > > > > See comment in systemd src/core/automount.c::automount_send_ready(). > > > > > > ... > > > > > > --- a/fs/autofs4/dev-ioctl.c > > > +++ b/fs/autofs4/dev-ioctl.c > > > @@ -344,7 +344,7 @@ static int autofs_dev_ioctl_fail(struct file *fp, > > > int status; > > > > > > token = (autofs_wqt_t) param->fail.token; > > > - status = param->fail.status ? param->fail.status : -ENOENT; > > > + status = param->fail.status < 0 ? param->fail.status : -ENOENT; > > > return autofs4_wait_release(sbi, token, status); > > > } > > > > Sounds serious. Was the absence of a cc:stable deliberate? > > You need CAP_SYS_ADMIN to get the ioctl even looked at. Doesn't that > mean the bug can only be triggered by a process that could easily do > worse? Think so, yes. > > Or do containers allow admins to give out CAP_SYS_ADMIN to untrusted > people?? I haven't been keeping up. Maybe, with docker root can start a container with --privileged to give the container admin capabilities. It may be the case that capabilities can be used now I don't know. > > Given how simple the patch is, it probably makes sense to add a > cc:stable, just in case. IMHO it needs to be applied to stable as well. > > Thanks, > NeilBrown -- To unsubscribe from this list: send the line "unsubscribe autofs" in
