Crash from arbitrary code object hashing

[P403n1x87]

Crash report

What happened?

When attempting to hash a code object that has arbitrary opcodes that include the INSTRUMENTED_* instructions, among others, the interpreter can crash with a segmentation fault. A simple reproducer is given by

from opcode import opmap

def f(): pass

hash(f.__code__.replace(co_code=bytes([opmap["INSTRUMENTED_LINE"], 0])))

This behaviour was introduced in 3.12 alongside the low-impact monitoring API. Whilst it is expected that executing arbitrary opcodes can lead to crashes, simply hashing a Python object should not have such strong side effects. A more real-life example can be obtained with the use of PyArmor to obfuscate bytecode. Attempting to hash an obfuscated code object can lead to a segmentation fault for the reason mentioned above.

CPython versions tested on:

3.12, 3.13, 3.14, 3.15, 3.16, CPython main branch

Operating systems tested on:

macOS

Output from running 'python -VV' on the command line:

No response

Linked PRs

• gh-154985: Fix crash when hashing a code object with crafted instrumented bytecode #154986

[picnixz]

We do not consider this a legitimate bug because it is messing up with internals. Sorry! +we closed previous similar issues

[P403n1x87]

Definitely your call, but the PyArmor use case seems legitimate, and we saw it cause crashes with our observability tools only because we were computing a code object hash for bookkeeping reasons.

[picnixz]

Mmh, if it is just about hashing we could make something but let me ask about it. We do not want to open a can of worm here.

cc @markshannon @iritkatriel @Fidget-Spinner

[picnixz]

For now I am reopening this. If we want to proceed we can reopen your PR later.

[markshannon]

1. f.__code__.replace(co_code=bytes([opmap["INSTRUMENTED_LINE"], 0])) is buggy. INSTRUMENTED_LINE is not a legal instruction
2. If we were to fix this, it would be by rejecting the code in code.replace

What's the PyArmor bug, is it using instrumented instructions, or something else?

[P403n1x87]

@markshannon here's an example of the obfuscated bytecode generated by PyArmor for a simple target function like

def add(x, y):
    total = x + y
    for _ in range(2):
        total += 1
    return total

plain add.__code__.co_code: 60 bytes
     0: 95 00 58 01 2d 00 00 00 6e 02 5b 01 00 00 00 00
    16: 00 00 00 00 53 01 35 01 00 00 00 00 00 00 13 00
    32: 48 08 00 00 6e 03 55 02 53 02 2d 0d 00 00 6e 02
    48: 4d 0a 00 00 0b 00 20 00 55 02 24 00

obfuscated add.__code__.co_code: 146 bytes
     0: 1e de 1e 70 53 02 22 00 53 03 34 01 36 00 20 00
    16: 95 00 53 01 6e 02 1e b7 1e 32 6c 49 00 00 00 00
    32: 00 00 00 00 00 fb 3d 4e 2d df 00 00 00 4f 00 22
    48: 5d c9 00 00 35 56 00 00 00 00 00 00 1b 5f 60 6d
    64: 35 10 00 00 00 00 00 00 00 d1 35 7d 00 00 00 00
    80: 00 00 1b a4 6c 2a 00 00 00 00 00 00 00 00 0b 11
    96: 38 03 73 51 00 b1 00 bb 21 00 53 06 1e 00 22 00
   112: 53 03 35 01 00 00 00 00 00 00 20 00 66 00 3d 03
   128: 1f 00 66 01 53 06 22 00 53 03 34 01 36 00 20 00
   144: 24 00

This example doesn't reproduce the crash, because it depends on what actual bytes PyArmor emits for the obfuscated version of the bytecode. So let's now assume that we have a function f that leads to the opcode for INSTRUMENTED_LINE to be generated for the obfuscated version of the bytecode. When one tries to hash that, for example

registry[add.__code__.co_code] = RegistryEntry(...)

the application crashes with a segmentation fault. Whilst this might seem exotic, this is the kind of stuff that debugger tools, such as coverage etc... would do to keep track of tracing information.

Aside: perhaps a bit more expected, and not as dramatic, is the fact that calling dis.dis on the obfuscated code object leads to random exceptions, such as

Traceback (most recent call last):
  File "/private/tmp/pyarmor-repro/compare_bytecode.py", line 41, in <module>
    show("obfuscated target.add", obfuscated.add.__code__)
    ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/private/tmp/pyarmor-repro/compare_bytecode.py", line 20, in show
    dis.dis(code)
    ~~~~~~~^^^^^^

  ...

  File "/Users/gabriele.tornetta/.pyenv/versions/3.13.13/lib/python3.13/dis.py", line 671, in _get_name_info
    argval = get_name(name_index, **extrainfo)
IndexError: tuple index out of range

I think this is something that one has to accept though. But the hard crash from the hashing is worth "fixing" in my opinion.