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? Or do containers allow admins to give out CAP_SYS_ADMIN to untrusted people?? I haven't been keeping up. Given how simple the patch is, it probably makes sense to add a cc:stable, just in case. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
