Bug#529326: marked as done (linux-2.6: CVE-2009-0787 information disclosure in ecryptfs)
Your message dated Mon, 18 May 2009 15:49:45 -0400
with message-id <20090518154945.67a6100f.michael.s.gilbert@gmail.com>
and subject line Re: Bug#529326: linux-2.6: CVE-2009-0787 information disclosure in ecryptfs
has caused the Debian Bug report #529326,
regarding linux-2.6: CVE-2009-0787 information disclosure in ecryptfs
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
529326: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529326
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-2.6
Version: 2.6.26-15lenny2
Severity: important
Tags: security
Hi,
The following CVE (Common Vulnerabilities & Exposures) id was
published for linux-2.6.
CVE-2009-0787[0]:
| The ecryptfs_write_metadata_to_contents function in the eCryptfs
| functionality in the Linux kernel 2.6.28 before 2.6.28.9 uses an
| incorrect size when writing kernel memory to an eCryptfs file header,
| which triggers an out-of-bounds read and allows local users to obtain
| portions of kernel memory.
If you fix the vulnerability please also make sure to include the
CVE id in your changelog entry.
For further information see:
[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0787
http://security-tracker.debian.net/tracker/CVE-2009-0787
--- End Message ---
--- Begin Message ---
On Mon, 18 May 2009 13:12:23 -0600, dann frazier wrote:
> My understanding is that this issue was introduced by 87b811c (in
> 2.6.28), which resulted in only a single page getting allocated for
> the headers even though the size of the headers maybe > the page size.
yes, after reviewing further, i believe you are correct. in 87b811c,
they fixed the null allocation corner case, but introduced this problem
since they chose to continue to use PAGE_CACHE_SIZE for max allocation,
which is more than necessary, and could allow malicious users to
potentially access the extra memory within that allocation.
mike
--- End Message ---
Reply to: