linux-kernel - Re: [LKML] [PATCH] Fix NULL pointer for Xen guests

lists.openwall.net		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 linux-cve-announce 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:	Tue, 27 Apr 2010 19:59:17 +0200
From:	Andrew Jones <drjones@...hat.com>
To:	Prarit Bhargava <prarit@...hat.com>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-kernel@...r.kernel.org, suresh.b.siddha@...el.com,
	x86@...nel.org, clalance@...hat.com
Subject: Re: [LKML] [PATCH] Fix NULL pointer for Xen guests

On 04/27/2010 07:09 PM, Prarit Bhargava wrote:
> 
> 
> On 04/27/2010 12:58 PM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Apr 27, 2010 at 11:24:42AM -0400, Prarit Bhargava wrote:
>>   
>>> Upstream PV guests fail to boot because of a NULL pointer.  It is
>>> possible that
>>> xen guests have irq_desc->chip_data = NULL.
>>>      
>> Can you provide a short example of test scenario? As in what I should do
>> to reproduce this problem?
>>    
> 
> Take the latest upstream (well ... to be honest, a bit older than that
> because of some other bugs) -- take 2.6.33 and try to boot it as a PV
> guest.  I'm using a RHEL5 Xen HV fwiw ...
> 
> P.

Another ingredient is to boot the guest with a configuration where its
maxvcpus is greater than its vcpus. If you have RHEL 5.5 userspace then
you can create a config with lines like this

maxvcpus = 4
vcpus = 2

with that you'll crash on boot. Then you can check that
irq_force_complete_move is on the stack if you have "preserve" for
on_crash and use xenctx to look at the state of the vcpus.

If the Xen you're using doesn't support the maxvcpus var, then I believe
you can do the same principle, but in a different way, using the
vcpus_avail var. Or, you can boot with > 1 vcpus and then attempt to
remove one with 'xm vcpu-set'.

Andrew

> 
>>> Test for NULL chip_data pointer before attempting to complete an irq
>>> move.
>>>
>>> Signed-off-by: Prarit Bhargava<prarit@...hat.com>
>>> Acked-by: Suresh Siddha<suresh.b.siddha@...el.com>
>>>
>>> diff --git a/arch/x86/kernel/apic/io_apic.c
>>> b/arch/x86/kernel/apic/io_apic.c
>>> index 127b871..eb2789c 100644
>>> --- a/arch/x86/kernel/apic/io_apic.c
>>> +++ b/arch/x86/kernel/apic/io_apic.c
>>> @@ -2545,6 +2545,9 @@ void irq_force_complete_move(int irq)
>>>       struct irq_desc *desc = irq_to_desc(irq);
>>>       struct irq_cfg *cfg = desc->chip_data;
>>>
>>> +    if (!cfg)
>>> +        return;
>>> +
>>>       __irq_complete_move(&desc, cfg->vector);
>>>   }
>>>   #else
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>      

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/