kernel BUG at mm/usercopy.c:72!

Balbir Singh bsingharora at gmail.com
Thu May 18 20:58:40 AEST 2017


On Thu, May 18, 2017 at 8:16 PM, Michael Ellerman <mpe at ellerman.id.au> wrote:
> Kees Cook <keescook at chromium.org> writes:
>> On Tue, May 16, 2017 at 4:09 AM, Michael Ellerman <mpe at ellerman.id.au> wrote:
>>> Yeah it looks like powerpc also suffers from the same bug that arm64
>>> used to, ie. virt_addr_valid() will return true for some vmalloc
>>> addresses.
>>>
>>> virt_addr_valid() is used pretty widely, I'm not sure if we can just fix
>>> it without other fallout. I'll dig a bit more tomorrow if no one beats
>>> me to it.
>>>
>>> Kees, depending on how that turns out we may ask you to revert
>>> 517e1fbeb65f ("mm/usercopy: Drop extra is_vmalloc_or_module() check").
>>
>> That's fine by me. Let me know what you think would be best.
>
> Oh man, what a mess.
>
> I think we can do a small fix for this in powerpc code for 4.12, will
> post it soon for Breno to test - I still can't reproduce locally.

To reproduce locally you'd need an alias'd 0xd000..<addr> mapped to a
0xc000..<addr> (due to the assumptions in __pa()) and with
virt_to_page(addr) have PageSlab(page) set, I guess. I guess with very
few modules, a whole lot of 0xd000... space is unused, but if we had a
bunch of modules and ended up with an 0xd000<addr> range aliased as
PageSlab you would probably run into it more easily.

Balbir Singh


More information about the Linuxppc-dev mailing list