Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Jan 2012 21:52:27 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: kernel: proc: clean up and fix /proc/<pid>/mem handling

On Wed, Jan 18, 2012 at 10:25:55AM +0800, Eugene Teo wrote:
> "Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
> robust, and it also doesn't match the permission checking of any of the
> other related files.

Anyone got a pointer to Jüri's report?  I suppose it was somewhere on
LKML, but I haven't found it yet.

I see how the checks against current->self_exec_id were insufficient for
security, yet maybe the report contained something else as well?

> This changes it to do the permission checks at open time, and instead of
> tracking the process, it tracks the VM at the time of the open.  That
> simplifies the code a lot, but does mean that if you hold the file
> descriptor open over an execve(), you'll continue to read from the _old_ VM.

I see it in the revised code, but I don't get it.  What does "the old
VM" mean after an execve()?  The code stores the mm pointer in
file->private_data, but is this stored pointer even valid after an
execve()?  (The code blindly assumes so, only checking for non-NULL.)

Was this discussed (on LKML or elsewhere)?

> http://git.kernel.org/linus/e268337dfe26dfc7efd422a804dbb27977a3cccc

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ