[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] kernel: tmpfs use-after-free
From:       Solar Designer <solar () openwall ! com>
Date:       2013-02-25 23:34:30
Message-ID: 20130225233430.GA9203 () openwall ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]