Bug#280492: kernel-source-2.4.27: strncpy does not 0-pad destination on some archs)
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-kernelm=105796021120436w=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]
Bug#280492: kernel-source-2.4.27: strncpy does not 0-pad destination on some archs)
I am uneasy about closing a valid bug that has not been completely fixed. But feel free to downgrade the importance/tags if you wish. However, I would feel better if you fixed it for the arches where we have a patch. Thanks, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280492: kernel-source-2.4.27: strncpy does not 0-pad destination on some archs)
Horms wrote: [snip] 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. Mips uses the generic version, the non-padding assembly one does only to_user/from_user, which is uncritical. 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? It could lead to involuntary disclosure of sensitive data. 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. AFAICS reassigning to alpha is ok. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280492: kernel-source-2.4.27: strncpy does not 0-pad destination on some archs)
reassign 280492 kernel-image-2.4.27-alpha thanks On Tue, Jan 18, 2005 at 07:21:47PM +0100, Thiemo Seufer wrote: Horms wrote: [snip] 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. Mips uses the generic version, the non-padding assembly one does only to_user/from_user, which is uncritical. 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? It could lead to involuntary disclosure of sensitive data. 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. AFAICS reassigning to alpha is ok. Done :) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280492: kernel-source-2.4.27: strncpy does not 0-pad destination on some archs)
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-kernelm=105796021120436w=2 [2] http://www.ultramonkey.org/bugs/patch/linux-2.4.21-strncpy-zero-pad.patch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280492: kernel-source-2.4.27: strncpy does not 0-pad destination on some archs)
Thanks for the extra information. I will look into applying those patches. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
