Crash during encoding using UTF-16/32 and custom error handler

[ATalaba]

BPO	36819
Nosy	@malemburg, @doerwalter, @vstinner, @ezio-melotti, @serhiy-storchaka, @tonybaloney, @ATalaba, @iritkatriel
PRs	bpo-36819: Fix out-of-bounds writes in encoders #13134 bpo-36819: Fix crashes in built-in encoders with weird error handlers #28593
Files	encode_crash.py: Source code to replicate the crash

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/serhiy-storchaka'
closed_at = None
created_at = <Date 2019-05-06.18:51:21.426>
labels = ['interpreter-core', 'type-crash', '3.10', '3.11', 'expert-unicode', '3.9']
title = 'Crash during encoding using UTF-16/32 and custom error handler'
updated_at = <Date 2021-09-29.15:17:06.551>
user = 'https://github.com/ATalaba'

bugs.python.org fields:

activity = <Date 2021-09-29.15:17:06.551>
actor = 'doerwalter'
assignee = 'serhiy.storchaka'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core', 'Unicode']
creation = <Date 2019-05-06.18:51:21.426>
creator = 'atalaba'
dependencies = []
files = ['48305']
hgrepos = []
issue_num = 36819
keywords = ['patch']
message_count = 9.0
messages = ['341599', '341658', '402170', '402726', '402826', '402830', '402832', '402833', '402883']
nosy_count = 8.0
nosy_names = ['lemburg', 'doerwalter', 'vstinner', 'ezio.melotti', 'serhiy.storchaka', 'anthonypjshaw', 'atalaba', 'iritkatriel']
pr_nums = ['13134', '28593']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue36819'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']

[ATalaba]

The CPython interpreter write out-of-bounds of allocated memory in certain edge cases in the utf-16 and utf-32 encoders.

The attached script registers two error handlers that either write one ascii character, or two bytes, and tells the encoder to start again from the start of the encoding error. The script then tries to encode an invalid codepoint in either utf-16 or utf-32. Each of the calls to encode independently cause segfaults

Since the encoder starts over again and keeps trying to append the result of the error handler, the lack of proper re-allocations leads to a buffer overflow, and corrupts the stack.

[tonybaloney]

Easily reproduced on master, thanks

(lldb) run encode_crash.py
Process 14743 launched: '/Users/anthonyshaw/repo/cpython/python.exe' (x86_64)
Objects/unicodeobject.c:448: _PyUnicode_CheckConsistency: Assertion "((((((PyObject*)(op))->ob_type))->tp_flags & ((1UL << 28))) != 0)" failed
Enable tracemalloc to get the memory block allocation traceback

object : Process 14743 stopped

• thread Support "bpo-" in Misc/NEWS #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  frame #0: 0x00000001000b5c15 python.exe`PyObject_Repr(v=0x0000000101376f90) at object.c:535:11
  532 infinitely. */
  533 if (Py_EnterRecursiveCall(" while getting the repr of an object"))
  534 return NULL;
  -> 535 res = (*v->ob_type->tp_repr)(v);
  536 Py_LeaveRecursiveCall();
  537 if (res == NULL)
  538 return NULL;

[iritkatriel]

Reproduced on 3.11.

[serhiy-storchaka]

I am working on it, since it is more complex issue, and PR 13134 does not solve it.

1. This bug affects also other codecs implemented in C: ASCII, Latin1, UTF-8, etc.
2. It still crashes in UTF-16/32 encoders if the error handler returns a position less than the current position.
3. Incorrect exception can be raised if the error handler returns invalid string/bytes: a non-ASCII string or a bytes object consisting of not a whole number of units.
4. The code for standard error handlers and for decoders needs a revision too. I have some suspects.

We could just forbid error handlers returning position not in the range (start , end], but it can break some code, so it is better to do this only in a new release.

[vstinner]

We could just forbid error handlers returning position not in the range (start , end]

Yeah, that sounds like a reasonable solution. I don't see the point of returning a position outside this range. What would be the use case?

For me, the only corner case is the "ignore" error handler which returns an empty string, but it returns a position in this range, no?

it can break some code, so it is better to do this only in a new release.

Implementing custom error handlers is a rare use case, so it should only affect a minority of users. Moreover, IMO returning a position outside the valid range is a bug. It's common that security fixes change the behavior, like rejecting values which were previously acceptd, to prevent a Python crash.