Skip to content

[P1] Writable message length fields allow ExtraDataPtr to read past its allocation #240

Description

@drebbe-intrepid

Bug

ExtraDataPtr allocates exactly the tuple length, but the getter trusts mutable NumberBytesData/NumberBytesHeader instead of an allocation-capacity field. A later length change exposes memory beyond the buffer.

Reviewed commit: 45167e09de6b886cd451a4245f842c8221349711 (current master on 2026-09-15).
Source: src/object_spy_message.cpp:102; src/object_spy_message.cpp:188

Reproduction

import ics
m = ics.SpyMessage()
m.ExtraDataPtr = (17,)  # allocate one byte
m.NumberBytesData = 64
print(len(m.ExtraDataPtr))  # do not print the out-of-bounds contents

Observed / expected

The getter returns 64 bytes from a one-byte allocation. Expected rejection of the inconsistent length or a safe bound on reads. This can disclose unrelated heap bytes or crash. Protocol changes and packed header/data lengths also need to preserve the capacity invariant. No hardware is needed.

Suggested fix and regression coverage

Track owned payload capacity separately from protocol length fields, validate mutations and reads, and validate payload lengths before native transmit. Preserve legitimate received-message ownership semantics. Add tests for enlarging NumberBytesData/NumberBytesHeader and changing Protocol after assigning a payload.

Validation environment

Windows x64, CPython 3.14.5, extension rebuilt from the commit above. Hardware-dependent entry points below were exercised with a mock DLL, not a connected device. The existing 30 tests pass despite these findings.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions