[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130225233430.GA9203@openwall.com>
Date: Tue, 26 Feb 2013 03:34:30 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: kernel: tmpfs use-after-free
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
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.
