Re: CVE-2016-7097 causes acl leak

[Mark Salyzyn <salyzyn@android.com>]

On 12/14/2016 03:30 PM, Greg KH wrote:
> On Wed, Dec 14, 2016 at 12:20:50PM -0800, Mark Salyzyn wrote:
>> On 12/13/2016 04:00 PM, Greg KH wrote:
>>> On Tue, Dec 13, 2016 at 03:42:58PM -0800, Mark Salyzyn wrote:
>>>> On 12/12/2016 10:26 PM, Cong Wang wrote:
>>>>> On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn <salyzyn@android.com> wrote:
>>>>>> The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.
>>>>> Only the 9p case is obvious to me:
>>>>>
>>>>> diff --git a/fs/9p/acl.c b/fs/9p/acl.c
>>>>> index b3c2cc7..082d227 100644
>>>>> --- a/fs/9p/acl.c
>>>>> +++ b/fs/9p/acl.c
>>>>> @@ -277,6 +277,7 @@ static int v9fs_xattr_set_acl(const struct
>>>>> xattr_handler *handler,
>>>>>            case ACL_TYPE_ACCESS:
>>>>>                    if (acl) {
>>>>>                            struct iattr iattr;
>>>>> +                       struct posix_acl *old_acl = acl;
>>>>>
>>>>>                            retval = posix_acl_update_mode(inode,
>>>>> &iattr.ia_mode, &acl);
>>>>>                            if (retval)
>>>>> @@ -287,6 +288,7 @@ static int v9fs_xattr_set_acl(const struct
>>>>> xattr_handler *handler,
>>>>>                                     * by the mode bits. So don't
>>>>>                                     * update ACL.
>>>>>                                     */
>>>>> +                               posix_acl_release(old_acl);
>>>>>                                    value = NULL;
>>>>>                                    size = 0;
>>>>>                            }
>>>>>
>>>>>
>>>>> The rest are anti-pattern (modifying parameters on stack via address)
>>>>> but look correct.
>>>> Greg KH: Beware that this similar fix needs to be applied to _backports_ to
>>>> stable kernel trees on other filesystem driver that have the same pattern
>>>> (with local posix_acl_release(acl) calls). I have found that depending on
>>>> vintage these would include this driver 9p, and possibly gfs2, jfs and xfs.
>>>> Be aware.
>>> I don't understand what you mean here.  What needs to be "backported" to
>>> the stable tree?  What commit in Linus's tree do I pick?  If not a
>>> commit there, where is it?
>>>
>>> totally confused,
>>>
>>> greg k-h
>> In 3.10-stable if you took the original CVE-2016-7097 fix it could break
>> four file system drivers, the fix for each would 'look like' this one fix
>> for the 9p driver.
> Did I take the fix in 3.10-stable?  What was the git commit id?  Is 3.10
> "broken" in this way?  Is any other stable kernel broken?
>
> I still don't have any idea of what is going on here...
>
> greg k-h

Nothing is going on here, it is a heads up, eventually CVE's get 
backported to stable as we do take them in through those paths. Telling 
you to be aware that the original commit causes a leak, and my 
experience has found that the leak affects these four file system drivers.


-- Mark