>> * CVE-2012-4527: stack-based buffer overflow by encryption / decryption of >> overly long file names (Closes: #690924) > I've reviewed this and it looks mostly good. However, can you explain > why you chose ERRWIDTH=PATH_MAX+1024 vs. the redhat patch WIDTH=80? I don't know exactly. It sounds reasonable: - We want to print one file name possibly 2 with program_name. - In a case of a file crafted to exploit this, it is likely than only one name with be very large. Having a large buffer will show the end of the message and one insane name. - tmperr is a static buffer. Having it to 3k should not bring any trouble. There is only one instance. - The buffer is only used in printf so that this is not an issue either. Fell free to put the buffer size back to 128, or use only the 80 first bytes like redhat. Or increase it more to 2*MPATH_MAX+sizeof(largestmessage). This will fix the CVE in all cases. The obvious fix should be changing all the err_crit like functions to use va_args. But I believe it is beyond scope.
Attachment:
signature.asc
Description: This is a digitally signed message part.