James Hawkins wrote:
On 4/8/06, Colin Wright cdonline@tesco.net wrote:
So although it would always return 0 it could set a bogus error. In the -1 example above we have same-sized buffers so the error is bogus. Bug.
In the -2 example above we haven't even checked the strings so the error is bogus. Bug.
Like I said before, this isn't about WideCharToMultiByte being 'correct'; it's about the fact that Coverity's analysis of this function is wrong, leading to a false positive. The only person that's going to send in a string long enough to overflow the size of an int isn't going to care about the last error, only that the attack didn't work, because we don't return a negative length and we don't access the string with a negative index. Besides, anyone can overflow strlen with a long enough string in (I imagine) most libraries, so there's not much we can do about that. The expected behavior of this function goes out the window if a user uses a string that long, and we can't consider these bugs in that case.
-- James Hawkins
OK. I haven't read the details of the Coverity bug entry, so I didn't realise that it was saying that the impact of srclen < 0 was the use of a negative index.
There can be copying of the massive string by wcstombs_sbcs_slow, called by wine_cp_wcstombs, called by WideCharToMultiByte, but that increments the destination pointer so there wouldn't be access using a negative index.
Colin cdwine@tesco.net