linux-kernel - Re: [PATCH] xfs: Fix wrong error codes being returned

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <535524BE.7070704@oracle.com>
Date:	Mon, 21 Apr 2014 22:01:34 +0800
From:	Jeff Liu <jeff.liu@...cle.com>
To:	Brian Foster <bfoster@...hat.com>
CC:	Tuomas Tynkkynen <tuomas.tynkkynen@....fi>,
	linux-kernel@...r.kernel.org, xfs@....sgi.com
Subject: Re: [PATCH] xfs: Fix wrong error codes being returned


On 04/21 2014 21:09 PM, Brian Foster wrote:
> On Mon, Apr 21, 2014 at 08:46:39PM +0800, Jeff Liu wrote:
>> Hi Tuomas,
>>
>> On 04/21 2014 18:04 PM, Tuomas Tynkkynen wrote:
>>> xfs_{compat_,}attrmulti_by_handle could return an errno with incorrect
>>> sign in some cases. While at it, make sure ENOMEM is returned instead of
>>> E2BIG if kmalloc fails.
>>>
>>> Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@....fi>
>>> ---
>>> Compile tested only. For the ERANGE case, I also wonder if it should
>>> be assigning to ops[i].am_error instead of error, and/or have a break.
>>
>> If I understand right, ops[i].am_error is used to save the internal operation result,
>> i.e, xfs_attrmult_attr_get{set}... but error is used for the ioctl call results.
>> Therefore, assign ERANGE to error is compatible with the VFS set{get}xattr syscalls in
>> case of "if (ops[i].am_error == 0 || ops[i].am_error == MAXNAMELEN)".
>>
> 
> But we set 'error' in this case and effectively try to continue the operation
> whereas the traditional vfs path returns...

So the error would always be set to ERANGE if one or more attrname is/are invalid.

> 
>> It seems that we don't need to have a break in this case because xfs_attrmulti_by_handle()
>> is used to process multiple attrs.  Hence if a given attrname in ops array is invalid,
>> the am_error will indicate that with ENOATTR or EFAULT...but it should proceed to loop
>> through the left array members.
>>
> 
> Perhaps so if am_error == 0, but it depends on what attr_name contains
> at that point (stale data?). Otherwise, we try to proceed with a
> truncated name. It looks like the consistent thing to do would be set
> am_error to ERANGE and continue (i.e., skip the op and move on to the
> next).

If we continue to process a truncated name in case of MAXNAMELEN, it would return
EFAULT for SET/REMOVE operations, and ENOATTR for GET operation, which would be
set back to am_error, but error still keep as ERANGE which is consistently.


Thanks,
-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/