From: Sasha Levin <levinsasha928@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: lizf@cn.fujitsu.com, penberg@kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Tyler Hicks <tyhicks@canonical.com>,
Dustin Kirkland <kirkland@canonical.com>,
ecryptfs@vger.kernel.org
Subject: Re: [PATCH] mm: Don't warn if memdup_user fails
Date: Thu, 12 Jan 2012 10:06:34 +0200 [thread overview]
Message-ID: <1326355594.1999.7.camel@lappy> (raw)
In-Reply-To: <20120111141219.271d3a97.akpm@linux-foundation.org>
On Wed, 2012-01-11 at 14:12 -0800, Andrew Morton wrote:
> There's nothing particularly special about memdup_user(): there are
> many ways in which userspace can trigger GFP_KERNEL allocations.
>
> The problem here (one which your patch carefully covers up) is that
> ecryptfs_miscdev_write() is passing an unchecked userspace-provided
> `count' direct into kmalloc(). This is a bit problematic for other
> reasons: it gives userspace a way to trigger heavy reclaim activity and
> perhaps even to trigger the oom-killer.
>
> A better fix here would be to validate the incoming arg before using
> it. Preferably by running ecryptfs_parse_packet_length() before taking
> a copy of the data. That would require adding a small copy_from_user()
> to peek at the message header.
Let's split it to two parts: the specific ecryptfs issue I've given as
an example here, and a general view about memdup_user().
I fully agree that in the case of ecryptfs there's a missing validity
check, and just calling memdup_user() with whatever the user has passed
to it is wrong and dangerous. This should be fixed in the ecryptfs code
and I'll send a patch to do that.
The other part, is memdup_user() itself. Kernel warnings are usually
reserved (AFAIK) to cases where it would be difficult to notify the user
since it happens in a flow which the user isn't directly responsible
for.
memdup_user() is always located in path which the user has triggered,
and is usually almost the first thing we try doing in response to the
trigger. In those code flows it doesn't make sense to print a kernel
warnings and taint the kernel, instead we can simply notify the user
about that error and let him deal with it any way he wants.
There are more reasons kalloc() can show warnings besides just trying to
allocate too much, and theres no reason to dump kernel warnings when
it's easier to notify the user.
--
Sasha.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-01-12 8:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 16:50 [PATCH] mm: Don't warn if memdup_user fails Sasha Levin
2012-01-11 21:46 ` David Rientjes
2012-01-12 6:43 ` Pekka Enberg
2012-01-12 6:44 ` Pekka Enberg
2012-01-12 9:09 ` Li Zefan
2012-01-11 22:12 ` Andrew Morton
2012-01-12 7:12 ` Pekka Enberg
2012-01-12 8:06 ` Sasha Levin [this message]
2012-01-12 8:15 ` Pekka Enberg
2012-01-12 21:19 ` David Rientjes
2012-01-12 21:58 ` Andrew Morton
2012-01-12 22:29 ` David Rientjes
2012-01-13 7:17 ` Dan Carpenter
2012-01-13 7:36 ` Andrew Morton
2012-01-12 11:16 ` Tyler Hicks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1326355594.1999.7.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ecryptfs@vger.kernel.org \
--cc=kirkland@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=penberg@kernel.org \
--cc=tyhicks@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).