Skip to content

fix out-of-bounds read when packing ext data with overridden __len__ - #765

Open
kitkatt7 wants to merge 1 commit into
msgpack:mainfrom
kitkatt7:pack-ext-len-override
Open

kitkatt7 wants to merge 1 commit into
msgpack:mainfrom
kitkatt7:pack-ext-len-override

Conversation

@kitkatt7

@kitkatt7 kitkatt7 commented Nov 2, 2026

Copy link
Copy Markdown

Packer takes the ext body pointer from the bytes object's buffer but its length from len(). A bytes subclass can override __len__, so the length no longer matches the pointer and msgpack_pack_raw_body copies past the end of the buffer. Both the ExtType branch of _pack_inner (reached by packb(ExtType(code, data))) and Packer.pack_ext_type(code, data) are affected. Packing ExtType(0x42, data) where data is a bytes subclass whose __len__ returns 4096 but whose real length is 2 reads 4094 bytes beyond the payload into the output.

Size the body with Py_SIZE of the same object instead of len(), matching the bytes branch just above it. The pure Python fallback is not affected: it writes the real bytes and cannot read out of bounds.

test_pack_ext_type_len_override is skipped under the pure-Python fallback like the other C-extension-only tests. It fails on the unmodified extension (emits an ext 16 header claiming 4096 bytes) and passes after the change. Full test/ passes under both the C extension and MSGPACK_PUREPYTHON=1; ruff check and format pass.

The ext packing paths took the body pointer from the bytes object but
its length from len(), which a bytes subclass can override, so
msgpack_pack_raw_body copied past the buffer. Size the body with Py_SIZE
of the same object in _pack_inner and pack_ext_type.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant