linux-kernel - Possible race window when walking irq descriptors

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-next>] [day] [month] [year] [list]

Message-ID: <5571706A.60009@linux.intel.com>
Date:	Fri, 05 Jun 2015 17:48:26 +0800
From:	Jiang Liu <jiang.liu@...ux.intel.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Possible race window when walking irq descriptors

Hi Thomas,
File include/linux/irqnr.h provides several helper interfaces to walk
all/active irq descriptors. And the typical usage mode for those
interfaces is as below:
a)      for_each_irq_desc(i, desc) {
b)              do_pre_work();
c)              raw_spin_lock_irq(&desc->lock);
d)              deal_with_irq_desc(desc);
e)              raw_spin_unlock_irq(&desc->lock);
f)              do_post_work();
g)      }

When CONFIG_SPARSE_IRQ is enabled, irq descriptors will be freed when
freeing an irq. Thus there's a race window between step a) and step d).
Step c) may try to access already freed memory resources. Irq core uses
sparse_irq_lock to protect an irq descriptor from freeing, but not all
callers use sparse_irq_lock to protect returned irq descriptors.
A tree-wide scanning shows that:
1) Callers acquire sparse_irq_lock when walking irq deescriptors:
fs/proc/stat.c: show_stat()

2) Called from single-threaded environment:
drivers/sh/intc/core.c: intc_suspend() and intc_resume()
arch/ia64/hp/sim/hpsim_irq.c: hpsim_irq_init()
kernel/irq/proc.c: init_irq_proc()
kernel/irq/chip.c: suspend_device_irqs()/resume_device_irqs()
arch/powerpc/kernel/machine_kexec.c: machine_kexec_mask_interrupts()
arch/arm/kernel/machine_kexec.c: machine_kexec_mask_interrupts()
arch/x86/kernel/apic/io_apic.c: init_IO_APIC_traps()

3) Called stop_machine environment during cpu_down()
arch/arm/kernel/irq.c: migrate_irqs()
arch/arm64/kernel/irq.c: migrate_irqs()
arch/sh/kernel/irq.c: migrate_irqs()
arch/xtensa/kernel/irq.c: migrate_irqs()
arch/metag/kernel/irq.c: migrate_irqs()
arch/powerpc/kernel/irq.c: migrate_irqs()
arch/powerpc/sysdev/xics/xics-common.c:xics_migrate_irqs_away()
kernel/irq/chip.c:irq_cpu_offline()
arch/x86/kernel/irq.c: fixup_irqs()

4) Called during cpu_up()
kernel/irq/chip.c:irq_cpu_online()
arch/x86/kernel/apic/vector.c:__setup_vector_irq()

5) Called from free running process context
arch/x86/kernel/topology.c: arch_register_cpu()
arch/x86/kernel/apic/io_apic.c: print_IO_APICs()
kernel/irq/autoprobe.c: probe_irq_on()/probe_irq_mask()/probe_irq_off()

6) Called from free running interrupt context
kernel/irq/spurious.c: poll_spurious_irqs()/misrouted_irq()

So seems something needs to done to protect 4), 5) and 6). Is this
analysis correct? If so, I will try to work out some patches for it.
Thanks!
Gerry
--
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/