James Hawkins wrote:
On 4/8/06, Colin Wright <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
