[Xen-devel] Re: Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000

[Ian Campbell <ijc@xxxxxxxxxxxxxx>]

On Tue, 2011-09-20 at 14:20 +0100, Ben Hutchings wrote:
> On Tue, 2011-09-20 at 10:12 +0400, rush wrote:
> > Hi,
> > 
> > There are several Not tainted lines in old messages file. There are all of 
> > them:
> > 
> > Sep 10 22:35:33 xen-dom0 kernel: [24183.985513] Pid: 2605, comm:
> > debootstrap Not tainted 3.0.0-1-amd64 #1 Intel Corporation
> > S1200BTL/S1200BTL
> > Sep 10 22:35:33 xen-dom0 kernel: [24183.985621] RIP:
> > e030:[<ffffffff810106db>]  [<ffffffff810106db>]
> > __sanitize_i387_state+0x23/0xe1
> 
> Source/disassembly:
> 
> void __sanitize_i387_state(struct task_struct *tsk)
> {
>       u64 xstate_bv;
>       int feature_bit = 0x2;
>       struct i387_fxsave_struct *fx = &tsk->thread.fpu.state->fxsave;
> ffffffff810106b8:       48 8b 97 48 04 00 00    mov    0x448(%rdi),%rdx
> 
>       if (!fx)
>               return;
> ffffffff810106bf:       48 85 d2                test   %rdx,%rdx
> ffffffff810106c2:       0f 84 d0 00 00 00       je     0xffffffff81010798
> 
>       BUG_ON(task_thread_info(tsk)->status & TS_USEDFPU);
> ffffffff810106c8:       48 8b 47 08             mov    0x8(%rdi),%rax
> ffffffff810106cc:       f6 40 14 01             testb  $0x1,0x14(%rax)
> ffffffff810106d0:       74 02                   je     0xffffffff810106d4
> ffffffff810106d2:       0f 0b                   ud2    
> 
>       xstate_bv = tsk->thread.fpu.state->xsave.xsave_hdr.xstate_bv;
> ffffffff810106db:       48 8b b2 00 02 00 00    mov    0x200(%rdx),%rsi
> 
> So tsk->thread.fpu.state in RDX seems to be invalid.
> 
> > Sep 10 22:35:33 xen-dom0 kernel: [24183.985716] RSP:
> > e02b:ffff8803bd2c5e00  EFLAGS: 00010246
> > Sep 10 22:35:33 xen-dom0 kernel: [24183.985767] RAX: 0000000000000000
> > RBX: 00007fff3d69ecc0 RCX: 0000000000000200
> > Sep 10 22:35:33 xen-dom0 kernel: [24183.985824] RDX: ffff8803be0e8e00
> > RSI: ffff8803bd2c5fd8 RDI: ffff8803bd65aa30
> [...]
> 
> RDX looks like a reasonable kernel memory pointer.  Given the hostname,
> I assume this kernel is running under Xen.  So could this be a
> use-after-free where the freed page has been unmapped for reallocation
> by the hypervisor?  Can that happen to arbitrary pages in the dom0
> kernel?

In a modern pvops kernel there is a tendency towards leaving a page of
actual dom0 memory behind in these cases, rather than a hole. A page
with no backing mfn should never be escaping into the "wild" anyway but
it's possible fir a given process to see one if it is doing hypercall
activities, mapping foreign pages etc.

There's been some similar looking threads on xen-devel recently but I
haven't paid attention to the details, list & Konrad CC'd. Full log is
at http://bugs.debian.org/642154.

> 
> Ben.
> 

-- 
Ian Campbell

Everybody has something to conceal.
                -- Humphrey Bogart


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel