* [PATCH 3.3.0-rc3] Fix use-after-free in acpi_map_lsapic
@ 2012-02-16 0:06 Petr Vandrovec
2012-03-07 19:48 ` Alok Kataria
0 siblings, 1 reply; 5+ messages in thread
From: Petr Vandrovec @ 2012-02-16 0:06 UTC (permalink / raw)
To: lenb; +Cc: linux-kernel, linux-acpi, akataria, dcovelli
From: Petr Vandrovec <petr@vmware.com>
When processor is being hot-added to the system, acpi_map_lsapic invokes
ACPI _MAT method to find APIC ID and flags, verifies that returned structure
is indeed ACPI's local APIC structure, and that flags contain MADT_ENABLED
bit. Then saves APIC ID, frees structure - and accesses structure when
computing arguments for acpi_register_lapic call. Which sometime leads
to acpi_register_lapic call being made with second argument zero, failing
to bring processor online with error 'Unable to map lapic to logical cpu
number'.
As lapic->lapic_flags & ACPI_MADT_ENABLED was already confirmed to be non-zero
few lines above, we can just pass unconditional ACPI_MADT_ENABLED to the
acpi_register_lapic.
Thanks, Petr
Signed-off-by: Petr Vandrovec <petr@vmware.com>
Signed-off-by: Alok Kataria <akataria@vmware.com>
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index ce664f3..a4a0901 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -650,7 +650,7 @@ static int __cpuinit _acpi_map_lsapic(acpi_handle handle, int *pcpu)
goto free_tmp_map;
cpumask_copy(tmp_map, cpu_present_mask);
- acpi_register_lapic(physid, lapic->lapic_flags & ACPI_MADT_ENABLED);
+ acpi_register_lapic(physid, ACPI_MADT_ENABLED);
/*
* If mp_register_lapic successfully generates a new logical cpu
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 3.3.0-rc3] Fix use-after-free in acpi_map_lsapic
2012-02-16 0:06 [PATCH 3.3.0-rc3] Fix use-after-free in acpi_map_lsapic Petr Vandrovec
@ 2012-03-07 19:48 ` Alok Kataria
2012-03-08 21:01 ` Toshi Kani
0 siblings, 1 reply; 5+ messages in thread
From: Alok Kataria @ 2012-03-07 19:48 UTC (permalink / raw)
To: Petr Vandrovec, the arch/x86 maintainers
Cc: lenb, linux-kernel, linux-acpi, dcovelli
Len, anyone else,
Any comments on this one ? This fixes a important bug during cpu hotadd
where the kernel fails to recognize all the newly added cpus.
Thanks,
Alok
On Wed, 2012-02-15 at 16:06 -0800, Petr Vandrovec wrote:
> From: Petr Vandrovec <petr@vmware.com>
>
> When processor is being hot-added to the system, acpi_map_lsapic invokes
> ACPI _MAT method to find APIC ID and flags, verifies that returned structure
> is indeed ACPI's local APIC structure, and that flags contain MADT_ENABLED
> bit. Then saves APIC ID, frees structure - and accesses structure when
> computing arguments for acpi_register_lapic call. Which sometime leads
> to acpi_register_lapic call being made with second argument zero, failing
> to bring processor online with error 'Unable to map lapic to logical cpu
> number'.
>
> As lapic->lapic_flags & ACPI_MADT_ENABLED was already confirmed to be non-zero
> few lines above, we can just pass unconditional ACPI_MADT_ENABLED to the
> acpi_register_lapic.
>
> Thanks, Petr
>
> Signed-off-by: Petr Vandrovec <petr@vmware.com>
> Signed-off-by: Alok Kataria <akataria@vmware.com>
>
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index ce664f3..a4a0901 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -650,7 +650,7 @@ static int __cpuinit _acpi_map_lsapic(acpi_handle handle, int *pcpu)
> goto free_tmp_map;
>
> cpumask_copy(tmp_map, cpu_present_mask);
> - acpi_register_lapic(physid, lapic->lapic_flags & ACPI_MADT_ENABLED);
> + acpi_register_lapic(physid, ACPI_MADT_ENABLED);
>
> /*
> * If mp_register_lapic successfully generates a new logical cpu
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 3.3.0-rc3] Fix use-after-free in acpi_map_lsapic
2012-03-07 19:48 ` Alok Kataria
@ 2012-03-08 21:01 ` Toshi Kani
2012-03-08 21:33 ` Alok Kataria
0 siblings, 1 reply; 5+ messages in thread
From: Toshi Kani @ 2012-03-08 21:01 UTC (permalink / raw)
To: Alok Kataria
Cc: Petr Vandrovec, the arch/x86 maintainers, lenb, linux-kernel,
linux-acpi, dcovelli
On Wed, 2012-03-07 at 11:48 -0800, Alok Kataria wrote:
> Len, anyone else,
>
> Any comments on this one ? This fixes a important bug during cpu hotadd
> where the kernel fails to recognize all the newly added cpus.
>
> Thanks,
> Alok
>
>
> On Wed, 2012-02-15 at 16:06 -0800, Petr Vandrovec wrote:
> > From: Petr Vandrovec <petr@vmware.com>
> >
> > When processor is being hot-added to the system, acpi_map_lsapic invokes
> > ACPI _MAT method to find APIC ID and flags, verifies that returned structure
> > is indeed ACPI's local APIC structure, and that flags contain MADT_ENABLED
> > bit. Then saves APIC ID, frees structure - and accesses structure when
> > computing arguments for acpi_register_lapic call. Which sometime leads
> > to acpi_register_lapic call being made with second argument zero, failing
> > to bring processor online with error 'Unable to map lapic to logical cpu
> > number'.
> >
> > As lapic->lapic_flags & ACPI_MADT_ENABLED was already confirmed to be non-zero
> > few lines above, we can just pass unconditional ACPI_MADT_ENABLED to the
> > acpi_register_lapic.
> >
> > Thanks, Petr
> >
> > Signed-off-by: Petr Vandrovec <petr@vmware.com>
> > Signed-off-by: Alok Kataria <akataria@vmware.com>
> >
> >
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index ce664f3..a4a0901 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -650,7 +650,7 @@ static int __cpuinit _acpi_map_lsapic(acpi_handle handle, int *pcpu)
> > goto free_tmp_map;
> >
> > cpumask_copy(tmp_map, cpu_present_mask);
> > - acpi_register_lapic(physid, lapic->lapic_flags & ACPI_MADT_ENABLED);
> > + acpi_register_lapic(physid, ACPI_MADT_ENABLED);
The change looks good. I suggest you also add the following line to
prevent such bug in future.
kfree(buffer.pointer);
buffer.length = ACPI_ALLOCATE_BUFFER;
buffer.pointer = NULL;
+ lapic = NULL;
Thanks,
-Toshi
> >
> > /*
> > * If mp_register_lapic successfully generates a new logical cpu
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 3.3.0-rc3] Fix use-after-free in acpi_map_lsapic
2012-03-08 21:01 ` Toshi Kani
@ 2012-03-08 21:33 ` Alok Kataria
2012-03-08 22:34 ` Toshi Kani
0 siblings, 1 reply; 5+ messages in thread
From: Alok Kataria @ 2012-03-08 21:33 UTC (permalink / raw)
To: Toshi Kani
Cc: Petr Vandrovec, the arch/x86 maintainers, lenb, linux-kernel,
linux-acpi, dcovelli
Hi Toshi,
On Thu, 2012-03-08 at 14:01 -0700, Toshi Kani wrote:
> On Wed, 2012-03-07 at 11:48 -0800, Alok Kataria wrote:
> > Len, anyone else,
> >
> > Any comments on this one ? This fixes a important bug during cpu hotadd
> > where the kernel fails to recognize all the newly added cpus.
> >
> > Thanks,
> > Alok
> >
> >
> > On Wed, 2012-02-15 at 16:06 -0800, Petr Vandrovec wrote:
> > > From: Petr Vandrovec <petr@vmware.com>
> > >
> > > When processor is being hot-added to the system, acpi_map_lsapic invokes
> > > ACPI _MAT method to find APIC ID and flags, verifies that returned structure
> > > is indeed ACPI's local APIC structure, and that flags contain MADT_ENABLED
> > > bit. Then saves APIC ID, frees structure - and accesses structure when
> > > computing arguments for acpi_register_lapic call. Which sometime leads
> > > to acpi_register_lapic call being made with second argument zero, failing
> > > to bring processor online with error 'Unable to map lapic to logical cpu
> > > number'.
> > >
> > > As lapic->lapic_flags & ACPI_MADT_ENABLED was already confirmed to be non-zero
> > > few lines above, we can just pass unconditional ACPI_MADT_ENABLED to the
> > > acpi_register_lapic.
> > >
> > > Thanks, Petr
> > >
> > > Signed-off-by: Petr Vandrovec <petr@vmware.com>
> > > Signed-off-by: Alok Kataria <akataria@vmware.com>
> > >
> > >
> > > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > > index ce664f3..a4a0901 100644
> > > --- a/arch/x86/kernel/acpi/boot.c
> > > +++ b/arch/x86/kernel/acpi/boot.c
> > > @@ -650,7 +650,7 @@ static int __cpuinit _acpi_map_lsapic(acpi_handle handle, int *pcpu)
> > > goto free_tmp_map;
> > >
> > > cpumask_copy(tmp_map, cpu_present_mask);
> > > - acpi_register_lapic(physid, lapic->lapic_flags & ACPI_MADT_ENABLED);
> > > + acpi_register_lapic(physid, ACPI_MADT_ENABLED);
>
> The change looks good. I suggest you also add the following line to
> prevent such bug in future.
>
> kfree(buffer.pointer);
> buffer.length = ACPI_ALLOCATE_BUFFER;
> buffer.pointer = NULL;
> + lapic = NULL;
That's a good suggestion, below is the updated patch. Thanks !!
--
From: Petr Vandrovec <petr@vmware.com>
When processor is being hot-added to the system, acpi_map_lsapic invokes
ACPI _MAT method to find APIC ID and flags, verifies that returned structure
is indeed ACPI's local APIC structure, and that flags contain MADT_ENABLED
bit. Then saves APIC ID, frees structure - and accesses structure when
computing arguments for acpi_register_lapic call. Which sometime leads
to acpi_register_lapic call being made with second argument zero, failing
to bring processor online with error 'Unable to map lapic to logical cpu
number'.
As lapic->lapic_flags & ACPI_MADT_ENABLED was already confirmed to be non-zero
few lines above, we can just pass unconditional ACPI_MADT_ENABLED to the
acpi_register_lapic.
Signed-off-by: Petr Vandrovec <petr@vmware.com>
Signed-off-by: Alok N Kataria <akataria@vmware.com>
Cc : Toshi Kani <toshi.kani@hp.com>
Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c 2012-01-24 14:48:56.000000000 -0800
+++ linux-2.6/arch/x86/kernel/acpi/boot.c 2012-03-08 13:25:39.000000000 -0800
@@ -642,6 +642,7 @@ static int __cpuinit _acpi_map_lsapic(ac
kfree(buffer.pointer);
buffer.length = ACPI_ALLOCATE_BUFFER;
buffer.pointer = NULL;
+ lapic = NULL;
if (!alloc_cpumask_var(&tmp_map, GFP_KERNEL))
goto out;
@@ -650,7 +651,7 @@ static int __cpuinit _acpi_map_lsapic(ac
goto free_tmp_map;
cpumask_copy(tmp_map, cpu_present_mask);
- acpi_register_lapic(physid, lapic->lapic_flags & ACPI_MADT_ENABLED);
+ acpi_register_lapic(physid, ACPI_MADT_ENABLED);
/*
* If mp_register_lapic successfully generates a new logical cpu
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 3.3.0-rc3] Fix use-after-free in acpi_map_lsapic
2012-03-08 21:33 ` Alok Kataria
@ 2012-03-08 22:34 ` Toshi Kani
0 siblings, 0 replies; 5+ messages in thread
From: Toshi Kani @ 2012-03-08 22:34 UTC (permalink / raw)
To: Alok Kataria
Cc: Petr Vandrovec, the arch/x86 maintainers, lenb, linux-kernel,
linux-acpi, dcovelli
Hi Alok,
On Thu, 2012-03-08 at 13:33 -0800, Alok Kataria wrote:
> Hi Toshi,
>
> >
> > The change looks good. I suggest you also add the following line to
> > prevent such bug in future.
> >
> > kfree(buffer.pointer);
> > buffer.length = ACPI_ALLOCATE_BUFFER;
> > buffer.pointer = NULL;
> > + lapic = NULL;
>
> That's a good suggestion, below is the updated patch. Thanks !!
Looks good. Thanks for the update.
-Toshi
> --
>
> From: Petr Vandrovec <petr@vmware.com>
>
> When processor is being hot-added to the system, acpi_map_lsapic invokes
> ACPI _MAT method to find APIC ID and flags, verifies that returned structure
> is indeed ACPI's local APIC structure, and that flags contain MADT_ENABLED
> bit. Then saves APIC ID, frees structure - and accesses structure when
> computing arguments for acpi_register_lapic call. Which sometime leads
> to acpi_register_lapic call being made with second argument zero, failing
> to bring processor online with error 'Unable to map lapic to logical cpu
> number'.
>
> As lapic->lapic_flags & ACPI_MADT_ENABLED was already confirmed to be non-zero
> few lines above, we can just pass unconditional ACPI_MADT_ENABLED to the
> acpi_register_lapic.
>
> Signed-off-by: Petr Vandrovec <petr@vmware.com>
> Signed-off-by: Alok N Kataria <akataria@vmware.com>
> Cc : Toshi Kani <toshi.kani@hp.com>
>
>
> Index: linux-2.6/arch/x86/kernel/acpi/boot.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c 2012-01-24 14:48:56.000000000 -0800
> +++ linux-2.6/arch/x86/kernel/acpi/boot.c 2012-03-08 13:25:39.000000000 -0800
> @@ -642,6 +642,7 @@ static int __cpuinit _acpi_map_lsapic(ac
> kfree(buffer.pointer);
> buffer.length = ACPI_ALLOCATE_BUFFER;
> buffer.pointer = NULL;
> + lapic = NULL;
>
> if (!alloc_cpumask_var(&tmp_map, GFP_KERNEL))
> goto out;
> @@ -650,7 +651,7 @@ static int __cpuinit _acpi_map_lsapic(ac
> goto free_tmp_map;
>
> cpumask_copy(tmp_map, cpu_present_mask);
> - acpi_register_lapic(physid, lapic->lapic_flags & ACPI_MADT_ENABLED);
> + acpi_register_lapic(physid, ACPI_MADT_ENABLED);
>
> /*
> * If mp_register_lapic successfully generates a new logical cpu
>
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-03-08 22:34 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-16 0:06 [PATCH 3.3.0-rc3] Fix use-after-free in acpi_map_lsapic Petr Vandrovec
2012-03-07 19:48 ` Alok Kataria
2012-03-08 21:01 ` Toshi Kani
2012-03-08 21:33 ` Alok Kataria
2012-03-08 22:34 ` Toshi Kani
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.