Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jan 2010 00:41:04 -0500 (EST)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: oss-security@...ts.openwall.com
cc: Josh Bressers <bressers@...hat.com>,
        "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE request - kernel: untangle the do_mremap()
 mess


On Wed, 20 Jan 2010, Eugene Teo wrote:

> 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 defer to Josh on this, but in a series of patches that is referred to as 
"mremap/mmap mess" in some linux-kernel subject lines, for which a 
specialist like Eugene is not entirely certain about, in which some of the 
patches are assembly-level changes for individual architectures, and where 
few of the patch diffs make it clear what the underlying problem was - we 
could collectively spend a week of labor trying to figure everything out 
from a purist CVE perspective, or anchor on a single series of commits 
that are hopefully attached to a single kernel RC or minor version 
release.  I suspect the latter would be more helpful to the general CVE 
consumer community, so my recommendation is for a single CVE, assuming 
that all of these patches make it into a single kernel update.

- Steve

P.S. for those with a long memory, the vim issues were different, just 
don't ask me how.


> 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:
> 1) untangling do_mremap(), part 1
> 54f5de709984bae0d31d823ff03de755f9dcac54
> http://marc.info/?l=linux-arch&m=126015794920298&w=2
> 2) do_mremap() untangling, part 2
> ecc1a8993751de4e82eb18640d631dae1f626bd6
> http://marc.info/?l=linux-arch&m=126015795020304&w=2
> 3) do_mremap() untangling, part 3
> 1a0ef85f84feb13f07b604fcf5b90ef7c2b5c82f
> http://marc.info/?l=linux-arch&m=126015799020341&w=2
> 4) fix checks for expand-in-place mremap
> f106af4e90eadd76cfc0b5325f659619e08fb762
> http://marc.info/?l=linux-kernel&m=126015827720681&w=2
> 5) fix the arch checks in MREMAP_FIXED case
> 097eed103862f9c6a97f2e415e21d1134017b135
> http://marc.info/?l=linux-kernel&m=126015827720686&w=2
> 6) fix pgoff in "have to relocate" case of mremap()
> 935874141df839c706cd6cdc438e85eb69d1525e
> http://marc.info/?l=linux-kernel&m=126015825720659&w=2
> 7) kill useless checks in sparc mremap variants
> 0ec62d290912bb4b989be7563851bc364ec73b56
> http://marc.info/?l=linux-kernel&m=126015822220608&w=2
> 8) file ->get_unmapped_area() shouldn't duplicate work of get_unmapped_area()
> c4caa778157dbbf04116f0ac2111e389b5cd7a29
> http://marc.info/?l=linux-arch&m=126015804620397&w=2
> 9) arm: add arch_mmap_check(), get rid of sys_arm_mremap()
> 2ea1d13f64efdf49319e86c87d9ba38c30902782
> http://marc.info/?l=linux-arch&m=126015819820566&w=2
> 10) Kill ancient crap in s390 compat mmap
> 570dcf2c15463842e384eb597a87c1e39bead99b
> http://marc.info/?l=linux-kernel&m=126015810620436&w=2
> 11) arch_mmap_check() on mn10300
> 564b3bffc619dcbdd160de597b0547a7017ea010
> http://marc.info/?l=linux-kernel&m=126015810620439&w=2
> 12) Cut hugetlb case early for 32bit on ia64
> 0067bd8a55862ac9dd212bd1c4f6f5bff1ca1301
> http://marc.info/?l=linux-kernel&m=126015810620442&w=2
> 13) Unify sys_mmap*
> f8b7256096a20436f6d0926747e3ac3d64c81d24
> http://marc.info/?l=linux-kernel&m=126015815920506&w=2
> 14) fix a struct file leak in do_mmap_pgoff()
> 8c7b49b3ecd48923eb64ff57e07a1cdb74782970
> http://marc.info/?l=linux-kernel&m=126015815920509&w=2
> 15) Take arch_mmap_check() into get_unmapped_area()
> 9206de95b1ea68357996ec02be5db0638a0de2c1
> http://marc.info/?l=linux-kernel&m=126015815920512&w=2
> 16) switch do_brk() to get_unmapped_area()
> 2c6a10161d0b5fc047b5bd81b03693b9af99fab5
> http://marc.info/?l=linux-arch&m=126015810820457&w=2
> 17) sparc_brk() is not needed anymore
> 05d72faa6d13c9d857478a5d35c85db9adada685
> http://marc.info/?l=linux-arch&m=126015810920463&w=2
> 18) Get rid of open-coding in ia64_brk()
> bb52d6694002b9d632bb355f64daa045c6293a4e
> http://marc.info/?l=linux-arch&m=126015811020469&w=2
> 19) fix broken aliasing checks for MAP_FIXED on sparc32,mips,arm and sh
> e77414e0aad6a1b063ba5e5750c582c75327ea6a
> http://marc.info/?l=linux-arch&m=126015816020518&w=2
> 20) Add missing alignment check in arch/score sys_mmap()
> aa65607373a4daf2010e8c3867b6317619f3c1a3
>
> Reference:
> https://bugzilla.redhat.com/show_bug.cgi?id=556703
>
> Thanks, Eugene
>

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.