Skip to content

Fix #73246: XMLReader: encoding length not checked #6899

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

cmb69
Copy link
Member

@cmb69 cmb69 commented Apr 22, 2021

libxml2 expects the passed encoding to be NUL terminated, so we reject
strings with NUL bytes right away.

libxml2 expects the passed encoding to be NUL terminated, so we reject
strings with NUL bytes right away.
@cmb69 cmb69 added the Bug label Apr 22, 2021
Copy link
Member

@nikic nikic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LG, but I don't think this meaningfully addresses bug #73246.

@cmb69
Copy link
Member Author

cmb69 commented Apr 26, 2021

Well, the reported stack-overflow looks like an issue in the iconv_open() implementation; the function is supposed to receive two arbitrary C strings, but apparently can't handle very long C strings. But even if some iconv_open() implementation documents a maximum length, that should be handled by the calling code, i.e. libxml2. Of course, we could restrict the length, but what should be the limit?

@cmb69 cmb69 closed this in 272df44 May 3, 2021
@cmb69 cmb69 deleted the cmb/73246 branch May 3, 2021 10:31
@nikic
Copy link
Member

nikic commented May 3, 2021

Well, the reported stack-overflow looks like an issue in the iconv_open() implementation; the function is supposed to receive two arbitrary C strings, but apparently can't handle very long C strings. But even if some iconv_open() implementation documents a maximum length, that should be handled by the calling code, i.e. libxml2. Of course, we could restrict the length, but what should be the limit?

Oh, I do agree that this is not our problem and we shouldn't address it from our side. Just saying that this fix isn't really related to that issue...

@cmb69
Copy link
Member Author

cmb69 commented May 3, 2021

Well, would have been better to close that ticket as not a bug, and to open a new one regarding the NUL bytes, but I think it has been okay-ish to "retarget" the ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants