On Thu, Jun 15 2017, Andrew Morton wrote:

> On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown <neilb@suse.com> 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