CAN-2003-0465 The kernel strncpy function in Linux 2.4 and 2.5 does not %NUL pad the buffer on architectures other than x86, as opposed to the expected behavior of strncpy as implemented in libc, which could lead to information leaks. http://marc.theaimsgroup.com/?l=linux-kernel&m=105796021120436&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=105796415223490&w=2 2.4: 1.1063.4.25 paulus|ChangeSet|20030812235114|14554 [hence fixed upstream in 2.4.22] Not fixed up to 2.4.21-7.EL
Created attachment 97323 [details] The s390,s390x test fix
Created attachment 97329 [details] ppc64 patch Thought I'd follow Pete's lead and attach the ppc64 patch here as well.
Created attachment 97337 [details] Correct s390 version from Martin (2.6)
Created attachment 97343 [details] Patch for generic kernel strncpy Amazingly enough, x86_64 doesn't have arch-specific string routines; it uses the generic routines in lib (this is true upstream as well, for both 2.4 and 2.6) Attached is a patch to drop-in the 2.6 version of strncpy, which does the right thing.
ia64 uses the generic routines as well.
The fixes required to make the x86_64, ia64, ppc64, s390, and s390x versions of strncpy() zero-pad the destination buffer were committed to the RHEL3 U2 patch pool tonight. They will first be available in kernel version 2.4.21-9.7.EL.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2004-188.html