bpo-32583: Fix possible crashing in builtin Unicode decoders#5325
bpo-32583: Fix possible crashing in builtin Unicode decoders#5325zhangyangyu merged 2 commits intopython:masterfrom
Conversation
298adef to
648a61d
Compare
When using customized decode error handlers, it is possible for builtin decoders to write out-of-bounds and then crash.
648a61d to
1c7c83a
Compare
|
@zhangyangyu: Please replace |
|
Thanks @zhangyangyu for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6. |
|
Sorry, @zhangyangyu, I could not cleanly backport this to |
…ythonGH-5325) When using customized decode error handlers, it is possible for builtin decoders to write out-of-bounds and then crash.. (cherry picked from commit 2c7fd46)
|
GH-5459 is a backport of this pull request to the 3.6 branch. |
| } | ||
| new_inptr = *input + newpos; | ||
| if (*inend - new_inptr > remain) { | ||
| /* We don't know the decoding algorithm here so we make the worst |
There was a problem hiding this comment.
The error handler registered with codecs.register_error can produce any string as an output. This output will be inserted in the buffer you allocate. So I propose to expect that decoded output could be bigger and either check that and reallocate the buffer or raise a MemoryError exception with proper description.
There was a problem hiding this comment.
Thanks for your review @sibiryakov . But the situation you mention has already been handled. See the previous condition replen - 1, if the handler returns any string longer than one, need_to_grow will be set and we will allocate more memory.
…5325) When using customized decode error handlers, it is possible for builtin decoders to write out-of-bounds and then crash.
https://bugs.python.org/issue32583