linux-kernel - Re: [PATCH] x86: add missing free_memtype if get_vm_area

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]

Message-ID: <20091104105149.GC13194@elte.hu>
Date:	Wed, 4 Nov 2009 11:51:49 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Xiaotian Feng <dfeng@...hat.com>
Cc:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, venkatesh.pallipadi@...el.com,
	suresh.b.siddha@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: add missing free_memtype if get_vm_area_caller
	failed


* Xiaotian Feng <dfeng@...hat.com> wrote:

> When __ioremap_caller goes into get_vm_area, kernel already reserved
> memtype. so if get_vm_area fails, we need to free it before return.
> 
> Signed-off-by: Xiaotian Feng <dfeng@...hat.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
> Cc: Suresh Siddha <suresh.b.siddha@...el.com>
> ---
>  arch/x86/mm/ioremap.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 334e63c..7859f77 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -196,8 +196,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>  	 * Ok, go for it..
>  	 */
>  	area = get_vm_area_caller(size, VM_IOREMAP, caller);
> -	if (!area)
> +	if (!area) {
> +		free_memtype(phys_addr, phys_addr + size);
>  		return NULL;
> +	}
>  	area->phys_addr = phys_addr;
>  	vaddr = (unsigned long) area->addr;

Nice one!

Mind structuring this fix in a bit different way please?

The main cause of this bug is the following unclean resource-teardown 
pattern in __ioremap_caller():

	area = get_vm_area_caller(size, VM_IOREMAP, caller);
	if (!area)
		return NULL;
	area->phys_addr = phys_addr;
	vaddr = (unsigned long) area->addr;

	if (kernel_map_sync_memtype(phys_addr, size, prot_val)) {
		free_memtype(phys_addr, phys_addr + size);
		free_vm_area(area);
		return NULL;
	}

	if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot)) {
		free_memtype(phys_addr, phys_addr + size);
		free_vm_area(area);
		return NULL;
	}

see how repetitive it is, and how the return sequence is duplicated?

The way we do this is to add an error path to the tail of the function:

err_free_area:
	free_vm_area(area);
err_free_memtype:
	free_memtype(phys_addr, phys_addr + size);
	return NULL;

and changing the failure branches to:

	if (!area)
		goto err_free_memtype;
	...

	if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot))
		goto err_free_area;

etc.

Ok?
	
	Ingo
--
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/