lkml.org 
[lkml]   [2016]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] fs:Fix kmemleak leak warning in getname_flags about working on unitialized memory
From
Date
On 9/1/16 12:16 PM, Al Viro wrote:
> On Thu, Sep 01, 2016 at 08:10:44AM -0500, Eric Sandeen wrote:
>> On 8/4/16 8:57 AM, Al Viro wrote:
>>
>>> Don't feed the troll. On all paths leading to that place we have
>>> result->name = kname;
>>> len = strncpy_from_user(kname, filename, EMBEDDED_NAME_MAX);
>>> or
>>> result->name = kname;
>>> len = strncpy_from_user(kname, filename, PATH_MAX);
>>> with failure exits taken if strncpy_from_user() returns an error, which means
>>> that the damn thing has already been copied into.
>>>
>>> FWIW, it looks a lot like buggered kmemcheck; as usual, he can't be bothered
>>> to mention which kernel version would it be (let alone how to reproduce it
>>> on the kernel in question), but IIRC davej had run into some instrumentation
>>> breakage lately.
>>
>> The original report is in https://bugzilla.kernel.org/show_bug.cgi?id=120651
>> if anyone is interested in it.
>
> What the hell does that one have to getname_flags(), other than having
> attracted the same... something on the edge of failing the Turing Test?

Sigh, pasted the wrong one, thus making things worse.

I suppose reverse-engineering Nick is a fool's errand, only adding to the
noise, sorry. I'll stop. ;)

-Eric

\
 
 \ /
  Last update: 2016-09-17 09:58    [W:0.031 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site