linux-kernel - Re: [PATCH 3/3] genirq/irqdomain: Detect type race in irq_create_fwspec

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:   Fri, 20 Sep 2019 16:14:11 +0000
From:   "Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@...ia.com>
To:     Marc Zyngier <maz@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Grant Likely <grant.likely@...retlab.ca>
CC:     Mark Brown <broonie@...nsource.wolfsonmicro.com>,
        Jon Hunter <jonathanh@...dia.com>,
        "Glavinic-Pecotic, Matija (EXT - DE/Ulm)" 
        <matija.glavinic-pecotic.ext@...ia.com>,
        "Adamski, Krzysztof (Nokia - PL/Wroclaw)" 
        <krzysztof.adamski@...ia.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH 3/3] genirq/irqdomain: Detect type race in
 irq_create_fwspec_mapping()

Hi!

On 20/09/2019 18:07, Marc Zyngier wrote:
>> irq_create_fwspec_mapping() can race with itself during IRQ trigger type
>> configuration. Possible scenarios include:
>>
>> - Mapping exists, two irq_create_fwspec_mapping() running in parallel do
>>   not detect type mismatch, IRQ remains configured with one of the
>>   different trigger types randomly
>> - Second call to irq_create_fwspec_mapping() sees existing mapping just
>>   created by first call, but earlier irqd_set_trigger_type() call races
>>   with later irqd_set_trigger_type() => totally undetected, IRQ type
>>   is being set randomly to either one or another type
> Is that an actual thing? Frankly, the scenario you're describing here
> seems to carry the hallmarks of a completely broken system. Can you
> point at a system supported in mainline that would behave as such?

Briefly speaking, this race is about not-complaining in case of a broken
device tree. This is not something purely theoretical. I don't know if
DTs under arch/arm/boot/dts are all correct, but I saw a lot DTs from
silicone vendors and very little of them were 100% correct.

In other words, this patch repairs error-handling. With 100% correct
DTs (or ACPI tables, have you seen one 100% correct BTW? :)) it's
not required.

-- 
Best regards,
Alexander Sverdlin.