Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Jun 2015 13:25:19 +0530 (IST)
From: P J P <ppandit@...hat.com>
To: oss security list <oss-security@...ts.openwall.com>
cc: cve-assign@...re.org, "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: Re: CVE request Linux kernel: ns: user namespaces
 panic

   Hello Eric,

+-- On Thu, 4 Jun 2015, Eric W. Biederman wrote --+
| The core issue is that a unprivileged user could call umount(MNT_DETACH)
| and in the right circumstances gain access to every file on essentially
| any filesystem in the mount namespace.
... 
| The bug fix modifies umount(MNT_DETACH) to keeps mounts covered
| even after the actual umount.  That changes makes it unsafe for
| copy_tree to run on an unmounted mount tree because one of it's
| assumptions is violated.  Which assumption I do not remember at this
| late hour.  But I think it was something bad enough to cause a crash.
| I can not recall all of the details when reading through the code
| at this late hour.
| 
| Previously copy_tree on an unmounted tree would just return a single
| struct mount as all of the connections would have been cleanly removed.
| 
| So I believe cd4a40174b71acd021877341684d8bb1dc8ea4ae prevents a
| difficult to trigger crash if you have
| e0c9c0afd2fc958ffa34b697972721d81df8a56f applied.
| 
| e0c9c0afd2fc958ffa34b697972721d81df8a56f mnt: Update detach_mounts to leave mounts connected
| is the real bug fix that fixes a fairly scary issue.
| 
| I hope that helps.

  Yes, it does. Thank you so much for throwing light on the real issue and 
its corresponding fix. I appreciate it.

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ