[<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
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.
