Re: [patch 064/158] mm: add generic ptdump

Steven Price
2019-12-02T09:09:38Z

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