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

List:       oss-security
Subject:    Re: [oss-security] CVE request - kernel: untangle the do_mremap() mess
From:       Marcus Meissner <meissner () suse ! de>
Date:       2010-01-21 10:01:56
Message-ID: 20100121100156.GA28846 () suse ! de
[Download RAW message or body]

On Wed, Jan 20, 2010 at 11:38:30AM +0800, Eugene Teo wrote:
> On 01/20/2010 04:41 AM, Josh Bressers wrote:
> >----- "Eugene Teo"<eugene@redhat.com>  wrote:
> >>There's a pile of upstream commits that fixed issues that can lead to
> >>
> >>user-triggerable panics on supported boxes:
> >>http://groups.google.com/group/linux.kernel/msg/895f20870532241e.
> >>
> >>http://groups.google.co.jp/group/fa.linux.kernel/browse_thread/thread/8bf22336b1082090
> >
> >I don't think CVE ids can be assigned to this without more information. I'm
> >not knowledgeable enough, nor do I have the time to properly understand
> >this list.
> 
> And upstream continues to give us grief...
> 
> Anyway, Al summarised the mess here:
> http://marc.info/?l=linux-arch&m=126004438008670&w=2
> 
> And the pile of upstream commits were meant to address the problems 
> described AFAIK. It will probably make more sense to associate all these 
> related commits to just one CVE name.
> 
> I rated these cvss2=7.2/AV:L/AC:L/Au:N/C:C/I:C/A:C.
> 
> Here are the related links and patch descriptions:
> 6) fix pgoff in "have to relocate" case of mremap()
> 935874141df839c706cd6cdc438e85eb69d1525e
> http://marc.info/?l=linux-kernel&m=126015825720659&w=2

This is a long standing bug I think, where mremap with MREMAP_MAYMOVE set
of an address that was offset into a file seems to then use a different
offset into the file.

I cannot think of a security issue with it right now.

> 14) fix a struct file leak in do_mmap_pgoff()
> 8c7b49b3ecd48923eb64ff57e07a1cdb74782970
> http://marc.info/?l=linux-kernel&m=126015815920509&w=2

This one is likely a security issue.
The code however was introduced in 2.6.32, the hugetlb implementation
was very different in previous kernels.

Ciao, Marcus
[prev in list] [next in list] [prev in thread] [next in thread]