linux-kernel - Re: CVE-2016-7097 causes acl leak

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]

Date:   Tue, 13 Dec 2016 12:28:41 +0100
From:   Jan Kara <jack@...e.cz>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Mark Salyzyn <salyzyn@...roid.com>,
        LKML <linux-kernel@...r.kernel.org>,
        aneesh.kumar@...ux.vnet.ibm.com, Jan Kara <jack@...e.cz>
Subject: Re: CVE-2016-7097 causes acl leak

On Mon 12-12-16 22:26:09, Cong Wang wrote:
> On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn <salyzyn@...roid.com> wrote:
> >
> > The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.
> 
> 
> Only the 9p case is obvious to me:

Agreed and the patch below looks good to me. Please make it a proper patch
(including changelog, sign-off, etc.) and feel free to add my Reviewed-by
tag.

> 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.

I'm not sure what's so unusual about passing a pointer to a local variable
(in fact a function argument but they are no different in C) to another
function. I agree it is not the most straightforward code but it is not that
complicated either...

What is important is that a function that acquires a reference to an acl also
releases that reference. That is a common pattern. I.e. we don't pass "a
reference to an object", we just pass "a pointer to an object" to a
function and guarantee the pointer will stay valid while the function runs.
What does some function (in our case ->set_acl handler) do with the pointer
you passed it is it's internal bussiness.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR