* [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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox