On Sun, Dec 01, 2019 at 03:45:54PM +0000, Borislav Petkov wrote: > On Sun, Dec 01, 2019 at 04:21:19PM +0100, Borislav Petkov wrote: > > On Sun, Dec 01, 2019 at 04:10:11PM +0100, Borislav Petkov wrote: > > > So lemme first confirm it really is caused by those patches. > > > > Yeah, those patches are causing it. Tried your current master - it is OK > > - and then applied Andrew's patches I was CCed on, ontop, and I got in a > > VM: > > > > VFS: Mounted root (ext4 filesystem) readonly on device 8:2. > > devtmpfs: mounted > > Freeing unused kernel image (initmem) memory: 664K > > Write protecting kernel text and read-only data: 18164k > > NX-protecting the kernel data: 7416k > > BUG: kernel NULL pointer dereference, address: 00000014 > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x0000) - not-present page > > *pdpt = 0000000000000000 *pde = f000ff53f000ff53 > > Oops: 0000 [#1] PREEMPT SMP PTI > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0+ #3 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014 > > EIP: __lock_acquire.isra.0+0x2e8/0x4e0 > > Code: e8 bd a1 2f 00 85 c0 74 11 8b 1d 08 8f 26 c5 85 db 0f 84 05 1a 00 00 8d 76 00 31 db 8d 65 f4 89 d8 5b 5e 5f 5d c3 8d 74 26 00 <8b> 44 90 04 85 c0 0f 85 4c fd ff ff e9 33 fd ff ff 8d b4 26 00 00 > > EAX: 00000010 EBX: 00000010 ECX: 00000001 EDX: 00000000 > > ESI: f1070040 EDI: f1070040 EBP: f1073e04 ESP: f1073de0 > > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010097 > > CR0: 80050033 CR2: 00000014 CR3: 05348000 CR4: 001406b0 > > Call Trace: > > lock_acquire+0x42/0x60 > > ? __walk_page_range+0x4d9/0x590 > > _raw_spin_lock+0x22/0x40 > > ? __walk_page_range+0x4d9/0x590 > > __walk_page_range+0x4d9/0x590 > Thanks for looking into this. I've been able to reproduce it locally with that config and I can see what's going wrong here. walk_pte_range() is being called with end=0xffffffff, but the comparison in the function is: if (addr == end) break; So addr never actually equals end, it skips from 0xfffff000 to 0x0. This means the function continues walking straight off the end and dereferencing 'random' ptes. As a quick hack I modified the condition to: if (addr == end || !addr) break; and I can then boot the VM. Clearly that's not the correct solution - I'll go away and have a think about the cleanest way of handling this case and also do some more testing before I resubmit for 5.6. Sorry for the trouble and thanks again for investigating. Steve
