netdev - Re: ppp_deflate + kmalloc

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: <20110627.211558.640845527643065916.davem@davemloft.net>
Date:	Mon, 27 Jun 2011 21:15:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mjackson220.list@...il.com
Cc:	carlsonj@...kingcode.com, paulus@...ba.org,
	linux-ppp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: ppp_deflate + kmalloc

From: Martin Jackson <mjackson220.list@...il.com>
Date: Sun, 26 Jun 2011 23:17:54 +0200

> Thanks for the advice. Hopefully we can indeed remove these obscure
> PPP options from our configuration - I'll look into that.
> 
> However, the point still stands that a 4th order kmalloc is likely to
> fail (even our "embedded" device has 256MB RAM and slub allocator,
> after all), and the page allocation code regards anything above order
> 3 as unrealistic and doesn't invoke the OOM to try to satisfy it, so
> my view remains that this should be changed to vmalloc.

PPP is not the only place in the tree where we potentially have
this problem.

crypto/deflate.c:	stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
crypto/zlib.c:	stream->workspace = kzalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
drivers/net/bnx2x/bnx2x_main.c:	bp->strm->workspace = kmalloc(zlib_inflate_workspacesize(),
drivers/net/ppp_deflate.c:	state->strm.workspace = kmalloc(zlib_inflate_workspacesize(),
fs/binfmt_flat.c:	strm.workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
lib/zlib_inflate/infutil.c:	strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);

A particularly problematic case is binfmt_flat.c since this is used on
systems which lack an MMU, and therefore for which vmalloc() is not
applicable.

What I'll do for now is transform all of the networking cases, but
someone should think seriously about the remaining cases.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html