NeilBrown <neilb@xxxxxxxx> writes: > On Thu, Jun 15 2017, Andrew Morton wrote: >> On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown <neilb@xxxxxxxx> wrote: >>> --- 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. Yep. They can be configured individually in fact, eg: $ docker run --cap-drop=ALL --cap-add=sys_admin -it debian:jessie /bin/bash root@aedebe8c46e0:/# capsh --print Current: = cap_sys_admin+eip Bounding set =cap_sys_admin Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups= cheers -- To unsubscribe from this list: send the line "unsubscribe autofs" in
