oss-sec mailing list archives
Re: kernel: tmpfs use-after-free
From: Solar Designer <solar () openwall com>
Date: Tue, 26 Feb 2013 03:34:30 +0400
On Mon, Feb 25, 2013 at 08:50:12PM +0100, Jason A. Donenfeld wrote:
While everyone's going wild hndl->dump'ing with CVE-2013-1763, there's apparently been another silent security fix with 5f00110f7273f9ff04ac69a5f85bb535a4fd0987 [1]:tmpfs: fix use-after-free of mempolicy object The tmpfs remount logic preserves filesystem mempolicy if the mpol=M option is not specified in the remount request. A new policy can be specified if mpol=M is given. Before this patch remounting an mpol bound tmpfs without specifying mpol= mount option in the remount request would set the filesystem's mempolicy object to a freed mempolicy object.
Apparently, the bug is only triggerable on builds with CONFIG_NUMA. Otherwise mpol_parse_str() is dummy, so it never sets the mpol pointer (which I guess is then left at NULL both at original mount and at any remount).
How far back does this issue go? I see it in both 2.6.36 and 3.3. I did not look back further.
RHEL5'ish kernels appear not vulnerable: they directly use a couple of integers in place of mpol struct pointers. I did not check RHEL6.
The commit message goes on with details on how to trigger it. Note that as of 5eaf563e53294d6696e651466697eb9d491f3946 [2], you can now mount filesystems as an unprivileged user [...]
This is also relevant to OpenVZ (and perhaps to other container-based virtualization systems/patches for Linux), where in-container root can mount/remount tmpfs. While I did not check RHEL6 kernel code yet, I just had a quick look at OpenVZ's default config for those kernels, and it does include CONFIG_NUMA=y. So if the code has the vulnerability, then OpenVZ based on these kernels is likely affected. (Need to check this when I have more time, or maybe someone else will. Luckily, we're still at RHEL5'ish OpenVZ kernels in released Owl versions, and we also don't build them with CONFIG_NUMA.) Alexander
Current thread:
- kernel: tmpfs use-after-free Jason A. Donenfeld (Feb 25)
- Re: kernel: tmpfs use-after-free Kurt Seifried (Feb 25)
- Re: kernel: tmpfs use-after-free Solar Designer (Feb 25)