Bug#642154: BUG: unable to handle kernel paging request at ffff8803bb6ad000
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
Reply to: