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]
Message-ID: <a4d0973bae1c50d947e7f84f3ec63d8f@www.loen.fr>
Date:   Mon, 16 Dec 2019 14:23:34 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Guoheyi <guoheyi@...wei.com>
Cc:     <linux-kernel@...r.kernel.org>, <wanghaibin.wang@...wei.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>
Subject: Re: [PATCH] irq-gic-v3: fix NULL dereference of disabled  redist_base

On 2019-12-16 13:50, Guoheyi wrote:
> 在 2019/12/16 19:14, Marc Zyngier 写道:
>> Hi Heyi,
>>
>> On 2019-12-16 06:27, Heyi Guo wrote:
>>> If we use ACPI MADT GICC structure to pass single redistributor 
>>> base,
>>> and mark some GICC as disabled, we'll get below call trace during
>>> boot:
>>>
>>> [    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
>>> [    0.000000] GICv3: 256 SPIs implemented
>>> [    0.000000] GICv3: 0 Extended SPIs implemented
>>> [    0.000000] GICv3: Distributor has no Range Selector support
>>> [    0.000000] Unable to handle kernel paging request at virtual
>>> address 000000000000ffe8
>>> [    0.000000] Mem abort info:
>>> [    0.000000]   ESR = 0x96000004
>>> [    0.000000]   EC = 0x25: DABT (current EL), IL = 32 bits
>>> [    0.000000]   SET = 0, FnV = 0
>>> [    0.000000]   EA = 0, S1PTW = 0
>>> [    0.000000] Data abort info:
>>> [    0.000000]   ISV = 0, ISS = 0x00000004
>>> [    0.000000]   CM = 0, WnR = 0
>>> [    0.000000] [000000000000ffe8] user address but active_mm is 
>>> swapper
>>> [    0.000000] Internal error: Oops: 96000004 [#1] SMP
>>> [    0.000000] Modules linked in:
>>> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc1 
>>> #5
>>> [    0.000000] pstate: 20000085 (nzCv daIf -PAN -UAO)
>>> [    0.000000] pc : gic_iterate_rdists+0x58/0x130
>>> [    0.000000] lr : gic_iterate_rdists+0x80/0x130
>>> [    0.000000] sp : ffff8000113d3cb0
>>> [    0.000000] x29: ffff8000113d3cb0 x28: 0000000000000000
>>> [    0.000000] x27: 0000000000000000 x26: 0000000000000018
>>> [    0.000000] x25: 000000000000ffe8 x24: 000000000000003f
>>> [    0.000000] x23: ffff800010588040 x22: 00000000000005e8
>>> [    0.000000] x21: ffff8000113df7d0 x20: 0000030f00003f11
>>> [    0.000000] x19: 0000000000000000 x18: ffffffffffffffff
>>> [    0.000000] x17: 0000000014aeb8dc x16: 00000000c3ba0ccf
>>> [    0.000000] x15: ffff8000113d9908 x14: ffff8000913d3a37
>>> [    0.000000] x13: ffff8000113d3a45 x12: ffff800011402000
>>> [    0.000000] x11: ffff8000113d39d0 x10: ffff8000113db980
>>> [    0.000000] x9 : 00000000ffffffd0 x8 : ffff8000106dca98
>>> [    0.000000] x7 : 000000000000005b x6 : 0000000000000000
>>> [    0.000000] x5 : 0000000000000000 x4 : ffff8000128c0000
>>> [    0.000000] x3 : ffff8000128a0000 x2 : ffff0003fc3c7000
>>> [    0.000000] x1 : 0000000000000001 x0 : 000000000000ffe8
>>> [    0.000000] Call trace:
>>> [    0.000000]  gic_iterate_rdists+0x58/0x130
>>> [    0.000000]  gic_init_bases+0x200/0x4b4
>>> [    0.000000]  gic_acpi_init+0x148/0x284
>>> [    0.000000]  acpi_match_madt+0x4c/0x84
>>> [    0.000000]  acpi_table_parse_entries_array+0x188/0x278
>>> [    0.000000]  acpi_table_parse_entries+0x70/0x98
>>> [    0.000000]  acpi_table_parse_madt+0x40/0x50
>>> [    0.000000]  __acpi_probe_device_table+0x88/0xe4
>>> [    0.000000]  irqchip_init+0x38/0x40
>>> [    0.000000]  init_IRQ+0x168/0x19c
>>> [    0.000000]  start_kernel+0x328/0x508
>>> [    0.000000] Code: f90017b6 9b3a7f16 f8766853 8b190260 (b9400000)
>>> [    0.000000] ---[ end trace ae5cf232d924bfc1 ]---
>>> [    0.000000] Kernel panic - not syncing: Fatal exception
>>> [    0.000000] Rebooting in 3 seconds..
>>>
>>> In this case, nr_redist_regions counts all GICC structures but only
>>> enabled ones have redistributor mapped. So add check to avoid NULL
>>> deference of redist_base.
>>>
>>> Signed-off-by: Heyi Guo <guoheyi@...wei.com>
>>> Cc: Thomas Gleixner <tglx@...utronix.de>
>>> Cc: Jason Cooper <jason@...edaemon.net>
>>> Cc: Marc Zyngier <maz@...nel.org>
>>> ---
>>>  drivers/irqchip/irq-gic-v3.c | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3.c 
>>> b/drivers/irqchip/irq-gic-v3.c
>>> index d6218012097b..bd9d55cadef9 100644
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>> @@ -781,6 +781,13 @@ static int gic_iterate_rdists(int (*fn)(struct
>>> redist_region *, void __iomem *))
>>>          u64 typer;
>>>          u32 reg;
>>>
>>> +        /*
>>> +         * redist_base may be NULL if we use single_redist and 
>>> some GICC
>>> +         * structure is disabled.
>>> +         */
>>> +        if (!ptr)
>>> +            continue;
>>> +
>>>          reg = readl_relaxed(ptr + GICR_PIDR2) & 
>>> GIC_PIDR2_ARCH_MASK;
>>>          if (reg != GIC_PIDR2_ARCH_GICv3 &&
>>>              reg != GIC_PIDR2_ARCH_GICv4) { /* We're in trouble... 
>>> */
>>
>> This feels like the wrong fix. The redistributor region array should
>> be completely populated, and there is an assumption all over this 
>> driver
>> that there is no junk in these structures.
>
>
> Oh, I thought the place holder for disabled GICR in nr_redist_regions
> were for some special reason, like CPU hotplug. Now I know I was 
> wrong
> :)

CPU hotplug would imply that the redistributors are available.
My interpretation of the ACPI MADT GICC subtable is that the
redistributors are simply inaccessible when disabled.

Otherwise, it'd be legitimate to just map them and live with
redistributors that do not have a corresponding CPU (which we
otherwise do). See ebe2f8718007 for details.

If we need to support redistributors becoming enabled under our
feet, then we'll have to handle this in a different way. We're
not there yet.

>> You're seeing this because we don't track the number of *enabled* 
>> rdists,
>> and allocate the number of regions based on the number of overall 
>> GICC
>> entries instead of the number of enabled redistributors.
>>
>> How about this instead?
>
> It looks good to me, and works fine in my case.

Can I take this as a Tested-by: ?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ