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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
