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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1802281730310.1392@nanos.tec.linutronix.de>
Date:   Wed, 28 Feb 2018 17:49:47 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Keith Busch <keith.busch@...el.com>
Subject: Re: [PATCH 4.4 33/53] x86/apic/vector: Fix off by one in error
 path

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 <tglx@...utronix.de>
> > > 
> > > 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 <keith.busch@...el.com>
> > > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> > > Tested-by: Keith Busch <keith.busch@...el.com>
> > > Cc: stable@...r.kernel.org
> > > Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161217300.1823@nanos
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > 
> > > ---
> > >  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 <tglx@...utronix.de>

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 <ben.hutchings@...ethink.co.uk>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

---

--- 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;
 		}
 	}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ