On Wed, May 23, 2012 at 10:21 AM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Date: Wed, 23 May 2012 08:15:42 -0700
>
>> Btw, the x86 version these days actually zeroes the last bytes of the
>> word-at-a-time copy.
>
> I noticed, and that was the bug in the version I posted.
>
> I decided in the end to not do what x86 does because there's no
> cheap way to do it on big-endian. I simply moved the 'dst'
> store before the has_zero() test.
Yes, the original x86 code worked that way too, and it's how 3.4 does
thing there. It results in garbage at the end of the result string,
but since we consider that to be undefined data anyway (unlike the C
library standard strncpy() that zero-fills it), it's not a big deal.
The reason I changed it on x86 was that I was a *tiny* bit worried
that some kernel user would eventually possibly expose those garbage
bytes. *IF* we were to ever have code like
memset(buffer, 0, sizeof(buffer));
strncpy_from_user(buffer, ptr, sizeof(buffer-1));
this would matter, and could expose data that the user didn't *intent*
to expose.
We don't have anything like that right now as far as I can tell (and I
did check, although it was more like a "glance through all the
users"), so it's more of a "possible future issues" thing than
anything else.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
