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 <saly...@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 <j...@suse.com> SUSE Labs, CR