[<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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
