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,  7 Apr 2015 14:51:28 +0200
From:	Jiri Slaby <jslaby@...e.cz>
To:	stable@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, Joerg Roedel <jroedel@...e.de>,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>, Jan Beulich <JBeulich@...e.com>,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Yinghai Lu <yinghai@...nel.org>, alnovak@...e.com,
	joro@...tes.org, Ingo Molnar <mingo@...nel.org>,
	Jiri Slaby <jslaby@...e.cz>
Subject: [PATCH 3.12 119/155] x86/irq: Check for valid irq descriptor in check_irq_vectors_for_cpu_disable()

From: Joerg Roedel <jroedel@...e.de>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

commit d97eb8966c91f2c9d05f0a22eb89ed5b76d966d1 upstream.

When an interrupt is migrated away from a cpu it will stay
in its vector_irq array until smp_irq_move_cleanup_interrupt
succeeded. The cfg->move_in_progress flag is cleared already
when the IPI was sent.

When the interrupt is destroyed after migration its 'struct
irq_desc' is freed and the vector_irq arrays are cleaned up.
But since cfg->move_in_progress is already 0 the references
at cpus before the last migration will not be cleared. So
this would leave a reference to an already destroyed irq
alive.

When the cpu is taken down at this point, the
check_irq_vectors_for_cpu_disable() function finds a valid irq
number in the vector_irq array, but gets NULL for its
descriptor and dereferences it, causing a kernel panic.

This has been observed on real systems at shutdown. Add a
check to check_irq_vectors_for_cpu_disable() for a valid
'struct irq_desc' to prevent this issue.

Signed-off-by: Joerg Roedel <jroedel@...e.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Reviewed-by: Jiang Liu <jiang.liu@...ux.intel.com>
Cc: H. Peter Anvin <hpa@...or.com>
Cc: Jan Beulich <JBeulich@...e.com>
Cc: K. Y. Srinivasan <kys@...rosoft.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Prarit Bhargava <prarit@...hat.com>
Cc: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Yinghai Lu <yinghai@...nel.org>
Cc: alnovak@...e.com
Cc: joro@...tes.org
Link: http://lkml.kernel.org/r/20150204132754.GA10078@suse.de
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Signed-off-by: Jiri Slaby <jslaby@...e.cz>
---
 arch/x86/kernel/irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 39100783cf26..549b119ed781 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -291,6 +291,9 @@ int check_irq_vectors_for_cpu_disable(void)
 		irq = __this_cpu_read(vector_irq[vector]);
 		if (irq >= 0) {
 			desc = irq_to_desc(irq);
+			if (!desc)
+				continue;
+
 			data = irq_desc_get_irq_data(desc);
 			cpumask_copy(&affinity_new, data->affinity);
 			cpu_clear(this_cpu, affinity_new);
-- 
2.3.4

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ