Messages in this thread | | | Subject | SECURITY - data leakage due to incorrect strncpy implementation | From | Alan Cox <> | Date | 11 Jul 2003 22:45:37 +0100 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |