SECURITY - data leakage due to incorrect strncpy implementation

[Alan Cox]

On Gwe, 2003-07-11 at 20:04, Mikulas Patocka wrote:
> What's the difference there? strlcpy always creates null-terminated
> string, strncpy doesn't. strncpy in kernel (unlike user strncpy) does not
> pad the whole destination buffer with zeros (see comment and
> implementation in lib/string.c), so I don't see any point why strncpy
> should be more secure.

Lots of kernel drivers rely on the libc definition of strncpy. 

Lets update the bug report to "2.4 and 2.5 both leak arbitary kernel data
to user space" tho thankfully in small pieces. Fix required. (bcc'd to Mark to 
assign a CAN number)

And for 2.4-ac I'm going to simply go make strncpy do what it says in the
book. For 2.5 the same is true and cleaner (since those who use strlcpy
properly don't take any performance hit). Actually it may make sense to 
backport strlcpy for those odd performance critical ones.

I don't think its that serious a bug - the odds of getting a critical bit of
someone elses data are remarkably low but it wants fixing.

Alan