[CVE-2026-56410] xmlwf: protect resolveSystemId from integer overflow#1252
Conversation
hartwork
left a comment
There was a problem hiding this comment.
@netliomax25-code the suggested patch may not be enough, please see below:
|
This might be a silly question, but where does the + 2 come from? (I realise this is not being changed in this PR, but just wondering while we’re here adding overflow checks if the value overflowing is even the correct sum.) |
|
@Smattr you're right, the worst case is tcslen(base) (the part kept before the last separator) + tcslen(systemId) + 1 for the NUL, so +1 would be enough and +2 over-allocates by one char. Looks like a harmless off-by-one from the original commit rather than something load-bearing. I left it alone here to keep this PR scoped to the overflow guard, but happy to trim it to +1 in a separate change if you'd prefer. |
hartwork
left a comment
There was a problem hiding this comment.
@netliomax25-code thanks for the adjustments!
|
@Smattr @netliomax25-code I believe the additional "plus 1" was intended for insertion of a delimiter, just the code after at… libexpat/expat/xmlwf/xmlfile.c Lines 145 to 153 in 8d28505 …does not add a delimiter (but look for existing ones). My vote for a dedicated follow-up pull request. |
|
Agreed, follow-up it is. I'll open a separate PR to trim the +2 to +1 since nothing inserts a delimiter, so base + systemId + 1 for the NUL is all we need. Keeping this one scoped to the overflow guard. |
|
CVE-2026-56410 has been assigned |
resolveSystemId builds an absolute path by allocating (tcslen(base) + tcslen(systemId) + 2) * sizeof(XML_Char), then copies base and systemId in. systemId comes from an external entity SYSTEM identifier, so on a wide-char build the multiply can wrap and under-allocate, leaving the following tcscpy/tcscat to overflow the heap. Guard the count against SIZE_MAX / sizeof(XML_Char) before the malloc, like copyString does, and fall back to systemId as the malloc-failure path already does.