[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOJsxLEYY=ZO8QrxiWL6qAxPzsPpZj3RsF9cXY0Q2L44+sn7JQ@mail.gmail.com>
Date: Thu, 12 Jan 2012 10:15:50 +0200
From: Pekka Enberg <penberg@...nel.org>
To: Sasha Levin <levinsasha928@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, lizf@...fujitsu.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Tyler Hicks <tyhicks@...onical.com>,
Dustin Kirkland <kirkland@...onical.com>,
ecryptfs@...r.kernel.org
Subject: Re: [PATCH] mm: Don't warn if memdup_user fails
On Thu, Jan 12, 2012 at 10:06 AM, Sasha Levin <levinsasha928@...il.com> wrote:
> 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.
I think you missed Andrew's point. We absolutely want to issue a
kernel warning here because ecryptfs is misusing the memdup_user()
API. We must not let userspace processes allocate large amounts of
memory arbitrarily.
Pekka
--
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/
Powered by blists - more mailing lists