Re: CVE-2016-7097 causes acl leak

Jan Kara
2016-12-15T16:32:07Z

On Thu 15-12-16 07:22:30, Mark Salyzyn wrote:
> 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.

Original commit (073931017b49) fixing the CVE does not contain the leak.
The leak in 9p was there before that commit. But yes, a naive backport of
that commit into 3.10 will introduce new similar leaks into xfs and others.

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