Received: by 10.223.185.116 with SMTP id b49csp6403179wrg; Wed, 28 Feb 2018 08:50:51 -0800 (PST) X-Google-Smtp-Source: AH8x227AKAjScJvKHkiaMsDFzKnOOg2Gq0gWf1zLy1eeolt0VCtryFSBH9SvqbtvgqRmVvsAo/vN X-Received: by 10.98.153.157 with SMTP id t29mr18503973pfk.201.1519836651623; Wed, 28 Feb 2018 08:50:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519836651; cv=none; d=google.com; s=arc-20160816; b=ehR3gVkscqTCRTW0h0upY1z6QkR9I6GWSXkmIQ2QjkgxLN3RI+kjFVRHjirhDJWVW0 XN1lotnvjT928dmZVxhR0t0FCy0f/DIjeXOaHNsu4zuzndwzN2SKZrdza8iCNzPdeu0R G0h75ZNs8DkVA4EYsMif8jloVKtJjZGv/3L6Yh0LF06hP2KARtqDNmBYTN3lo+sWttlr 3ZQjyWDH+CerFnspYRo6Map6LTdDhmHApmU6vsYwFAwg9qXjEs5t2GCUmHiTuPCliFDB V8uq+fckU8+OWYN00UKf/5lW85D285xRzY1mY05WEDYUFYOcDtts3xcBiOMWTfzt2m5Q kFsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=HMRvxqpyciqVIGkxCdscmP6b0P742Bk4rxfeXhZwaeQ=; b=MHA38z3DfeKSS2HBOjQbiK5EgSEHQpwoFp4aaZV4TIXdPPJj+vOFJ/twDRj5Dn46dk mrHFMldMAIpG+DaPQQ3YuT6gxlMoyEUIuZ2YuekpzAjJY6DZ+7gsFP8Z03Xud4q7Cbna OJNBbUpaHp17M08T57gXDM8ayQ1o6xfIU/pg6HEu3d7H9luT1iPbqxiuJlk4Q802zkSH kPE8cnI13CBeLLvCa9s2lLxpPU4u9n6BU7cUlxAcNoTIDp5TKUasJmTluHpWqu8JUimq nlwc78u03vGDt3XOHTlrdOqkLM1Z/hYyx1qTlxBwXlNcawhpKhoIB0PsHW0VA+/44ZhN HshA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s9-v6si1526780plr.57.2018.02.28.08.50.36; Wed, 28 Feb 2018 08:50:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932745AbeB1Qt5 (ORCPT + 99 others); Wed, 28 Feb 2018 11:49:57 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:49067 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932709AbeB1Qt4 (ORCPT ); Wed, 28 Feb 2018 11:49:56 -0500 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1er4ru-0001pq-Cx; Wed, 28 Feb 2018 17:46:14 +0100 Date: Wed, 28 Feb 2018 17:49:47 +0100 (CET) From: Thomas Gleixner To: Ben Hutchings cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Keith Busch Subject: Re: [PATCH 4.4 33/53] x86/apic/vector: Fix off by one in error path In-Reply-To: Message-ID: References: <20180122083910.299610926@linuxfoundation.org> <20180122083911.776154720@linuxfoundation.org> <1518814661.3422.42.camel@codethink.co.uk> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1929272789-1519836591=:1392" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1929272789-1519836591=:1392 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Sat, 17 Feb 2018, Thomas Gleixner wrote: > On Fri, 16 Feb 2018, Ben Hutchings wrote: > > On Mon, 2018-01-22 at 09:40 +0100, Greg Kroah-Hartman wrote: > > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > > > ------------------ > > > > > > From: Thomas Gleixner > > > > > > commit 45d55e7bac4028af93f5fa324e69958a0b868e96 upstream. > > > > > > Keith reported the following warning: > > > > > > WARNING: CPU: 28 PID: 1420 at kernel/irq/matrix.c:222 irq_matrix_remove_managed+0x10f/0x120 > > >   x86_vector_free_irqs+0xa1/0x180 > > >   x86_vector_alloc_irqs+0x1e4/0x3a0 > > >   msi_domain_alloc+0x62/0x130 > > > > > > The reason for this is that if the vector allocation fails the error > > > handling code tries to free the failed vector as well, which causes the > > > above imbalance warning to trigger. > > > > > > Adjust the error path to handle this correctly. > > > > > > Fixes: b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors") > > > Reported-by: Keith Busch > > > Signed-off-by: Thomas Gleixner > > > Tested-by: Keith Busch > > > Cc: stable@vger.kernel.org > > > Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161217300.1823@nanos > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > --- > > >  arch/x86/kernel/apic/vector.c |    7 +++++-- > > >  1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > --- a/arch/x86/kernel/apic/vector.c > > > +++ b/arch/x86/kernel/apic/vector.c > > > @@ -359,14 +359,17 @@ static int x86_vector_alloc_irqs(struct > > >   irq_data->chip_data = data; > > >   irq_data->hwirq = virq + i; > > >   err = assign_irq_vector_policy(virq + i, node, data, info); > > > - if (err) > > > + if (err) { > > > + irq_data->chip_data = NULL; > > > + free_apic_chip_data(data); > > >   goto error; > > > > This doesn't look quite right for 4.4.y (or any stable branch before > > 4.15.y). When virq is a legacy IRQ this function doesn't allocate > > "data" and shouldn't free it. > > Bah. I'm a moron. Lemme look at that. Delta patch which fixes this below. Thanks, tglx 8<---------------------------------- Subject: x86/apic/vector: Handle legacy irq data correctly From: Thomas Gleixner The backport of upstream commit 45d55e7bac40 ("x86/apic/vector: Fix off by one in error path") missed to fixup the legacy interrupt data which is not longer available upstream. Handle legacy irq data correctly by clearing the legacy storage to prevent use after free. Fixes: 7fd133539289 ("x86/apic/vector: Fix off by one in error path") - 4.4.y Fixes: c557481a9491 ("x86/apic/vector: Fix off by one in error path") - 4.9.y Reported-by: Ben Hutchings Signed-off-by: Thomas Gleixner --- --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -91,8 +91,12 @@ static struct apic_chip_data *alloc_apic return NULL; } -static void free_apic_chip_data(struct apic_chip_data *data) +static void free_apic_chip_data(unsigned int virq, struct apic_chip_data *data) { +#ifdef CONFIG_X86_IO_APIC + if (virq < nr_legacy_irqs()) + legacy_irq_data[virq] = NULL; +#endif if (data) { free_cpumask_var(data->domain); free_cpumask_var(data->old_domain); @@ -316,11 +320,7 @@ static void x86_vector_free_irqs(struct apic_data = irq_data->chip_data; irq_domain_reset_irq_data(irq_data); raw_spin_unlock_irqrestore(&vector_lock, flags); - free_apic_chip_data(apic_data); -#ifdef CONFIG_X86_IO_APIC - if (virq + i < nr_legacy_irqs()) - legacy_irq_data[virq + i] = NULL; -#endif + free_apic_chip_data(virq + i, apic_data); } } } @@ -361,7 +361,7 @@ static int x86_vector_alloc_irqs(struct err = assign_irq_vector_policy(virq + i, node, data, info); if (err) { irq_data->chip_data = NULL; - free_apic_chip_data(data); + free_apic_chip_data(virq + i, data); goto error; } } --8323329-1929272789-1519836591=:1392--