On Mon, Jan 17, 2005 at 10:47:18AM +0100, [EMAIL PROTECTED] wrote: > package kernel-source-2.4.27 > reopen 280492 > thanks > > > Both 2.4 and 2.6 upstream do not NULL terminate dest > > if count is exceeded. This is documented in the kernel > > and appears to be quite intentional. I am closing this > > accordingly. > > I think you missed the point here. The problem is that if the copied > string is shorter than the destination buffer, part of the old contents of > the destination remains unchanged and might be leaked to userspace. This > behaviour IS fixed in 2.6, so upstream thinks it IS a (small) problem [1]. > > BTW, I found a patch for ppc64 and s390 [2]. > > > [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=105796021120436&w=2 > [2] http://www.ultramonkey.org/bugs/patch/linux-2.4.21-strncpy-zero-pad.patch
Thanks. This really is a very minor problem, and is mostly still not fixed in 2.6. Actually, the only places it seems to have been fixed are in the generic.c version and in the s390, the latter due to a restructure. The patch from ultramonkey.org above was fished out of a Red Hat Kernel RPM (by me). It still seems to be used in their latest kernel (27.0.1.EL.um.1), so I am going to apply that. But for the other architectures (mips and alpha) there does not seem to be a fix available. To be honest I am pretty dubious about the security tag on this bug, I don't believe there is a known exploit and at best the bug seems to be regarded as being minor. Would it be acceptable to remove the security tag? Would you be happy to have the bug closed by application of the patch you suggested? Or do you want to hold it open because of the outstanding mips and alpha problem? I am pretty tempted to mark it as upstream and wontfix and reprioritise as wishlist if that is the case. Perhaps splitting and reassigning to the relevant misps and alpha kernel-image packages. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
