linux-kernel - Re: [PATCH] Parisc: Check kmalloc return value before use the buffer in ccio-dma.c

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: <20100506040331.GC4902@bombadil.infradead.org>
Date:	Thu, 6 May 2010 00:03:31 -0400
From:	Kyle McMartin <kyle@...artin.ca>
To:	wzt.wzt@...il.com
Cc:	linux-kernel@...r.kernel.org, linux-parisc@...r.kernel.org,
	kyle@...artin.ca, deller@....de, jejb@...isc-linux.org
Subject: Re: [PATCH] Parisc: Check kmalloc return value before use the
	buffer in ccio-dma.c

On Thu, May 06, 2010 at 10:42:08AM +0800, wzt.wzt@...il.com wrote:
> +	if (!name) {
> +		printk(KERN_ERR "%s() failed to get enough memory\n", __func__);
> +		return ;
> +	}
> +
>  	snprintf(name, 14, "GSC Bus [%d/]", ioc->hw_path);

This code can't fail, since the failure case won't be handled by the
probe function, and will continue along without properly initializing
the resources and will fail later. While we could add proper error
handling, if these functions are called, the ccio IOMMU exists on the
machine, and without it, we can't do any DMA (amongst other things.)
So in that case, if this kmalloc fails (which it really shouldn't...)
we're pretty much screwed.

We can change it to GFP_ATOMIC|__GFP_NOFAIL so it will retry infinitely,
or we can panic in the error path with a nice error message so the users
knows why his machine isn't going to work.

I suggest the latter since you'll have the test to squelch gcc warnings
and such.

regards, Kyle

--
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/