Jim Meyering <[EMAIL PROTECTED]> writes: > Please let us know if this is of more than theoretical interest. > If it's the one I'm thinking of, there was so much slack in the other > terms contributing to that buffer's length that one would be very > hard-pressed to contrive circumstances to provoke an actual overrun.
The only circumstances that I can see is when the attacker has some control over user names, and can request a very long user name (or group), e.g. for a nonce account. This isn't likely in wuftpd-like scenarios. I could probably construct a scenario where it is possible, but it's not one I've ever run into myself. > I replaced these lines > dired_pos += width; > dired_pos++; > with this one > dired_pos += width + 1; Actually, it'd be better to uniformly use dired_pos += width; dired_pos++; since it works in some cases when the "width + 1" form does not work. For example, in the common case where int is 32-bits and size_t is 64-bits, "width + 1" will overflow when width is INT_MAX, but the two-line form will work correctly. (Admittedly it's not very likely for strlen (username) to be INT_MAX, but I'm sure you can arrange it with the Hurd. :-) _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
