lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20140814185420.GA26367@optiplex.redhat.com> Date: Thu, 14 Aug 2014 15:54:21 -0300 From: Rafael Aquini <aquini@...hat.com> To: Andrey Ryabinin <ryabinin.a.a@...il.com> Cc: Konstantin Khlebnikov <koct9i@...il.com>, Sasha Levin <sasha.levin@...cle.com>, Andrew Morton <akpm@...ux-foundation.org>, Vlastimil Babka <vbabka@...e.cz>, David Rientjes <rientjes@...gle.com>, Mel Gorman <mgorman@...e.de>, Joonsoo Kim <iamjoonsoo.kim@....com>, Dave Jones <davej@...hat.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>, Andrey Ryabinin <a.ryabinin@...sung.com> Subject: Re: mm: compaction: buffer overflow in isolate_migratepages_range On Thu, Aug 14, 2014 at 10:07:40PM +0400, Andrey Ryabinin wrote: > 2014-08-14 19:13 GMT+04:00 Rafael Aquini <aquini@...hat.com>: > > It still a harmless condition as before, but considering what goes above > > I'm now convinced & confident the patch proposed by Andrey is the real fix > > for such occurrences. > > > > I don't think that it's harmless, because we could cross page boundary here and > try to read from a memory hole. > I think isolate_migratepages_range() skips over holes, doesn't it? > And this code has more potential problems like use after free. Since > we don't hold locks properly here, > page->mapping could point to freed struct address_space. > Thinking on how things go for isolate_migratepages_range() and balloon pages, I struggle to find a way where that could happen. OTOH, I failed to see things more blatant before, so I won't argue here. Defensive programming is always better than negating possibilities ;) > We discussed this with Konstantin and he suggested a better solution for this. > If I understood him correctly the main idea was to store bit > identifying ballon page > in struct page (special value in _mapcount), so we won't need to check > mapping->flags. > I liked it. Something in the line of PageBuddy()/PAGE_BUDDY_MAPCOUNT_VALUE scheme. This is clearly cleaner than what we have in place today, and I'm ashamed I didn't think of it before. Thanks for pointing that out. Cheers, -- Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists