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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 3 Nov 2017 13:54:14 -0600
From:   Craig Bergstrom <>
To:     Ingo Molnar <>
Cc:     Linus Torvalds <>,
        Sander Eikelenboom <>,
        Boris Ostrovsky <>,
        Fengguang Wu <>,,
        Linux Kernel Mailing List <>,
        LKP <>
Subject: Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical
 addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

Just a follow up, since I said I would come back around this week.

I've come up with a couple patchsets that I'm going to attempt to test
internally before I sent out more widely.  I'm thinking it's
appropriate to mail out two changes:

 (1) Reject attempts to map physical memory addresses outside the
valid physical memory bus width of the system.  This should reject
mappings that will obviously break the page fault handler without
affecting any memory mapped devices.

 (2) Make a page fault handler that's called with a reserved bit set
kill the process instead of reboot the whole kernel. This is based on
Linus' comment "I think we might also look at just also handling the
whole RSVD page fault case more gracefully".

Standby while I test these changes.


On Fri, Oct 27, 2017 at 1:28 PM, Craig Bergstrom <> wrote:
> Sounds good.  Thanks for the context.
> I'll keep this on my plate and I'll turn something around once I've
> had a chance to test a bit, probably next week.
> On Fri, Oct 27, 2017 at 1:24 PM, Ingo Molnar <> wrote:
>> * Craig Bergstrom <> wrote:
>>> Reverting seems like the right approach at the moment.  My apologies
>>> for the breakage so late the in the cycle.
>> Note that there's no need for you to apologize and you carry exactly zero amount
>> of blame for the late-cycle breakage: it was my decision to send it to Linus so
>> quickly, you never asked for it to be sent upstream on such a short notice.
>> ( Classic "patch makes sense, looks good, other arches ar doing this too, and I
>>   tested it myself too on multiple systems, so it must be obviously fine for
>>   everyone" moment. )
>> Your change still makes sense from a robustness POV, so please send it again with
>> the suggested fixes - and I'll be more careful with the upstream merge this time.
>> Thanks,
>>         Ingo

Powered by blists - more mailing lists