Re: CVE request - kernel: untangle the do_mremap() mess

[Marcus Meissner <meissner () suse de>]

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