Vendored msgpack affected by CVE-2026-57585 (Unpacker crash after caught error) — fork lacks context reset in unpack_clear

Summary

CVE-2026-57585 (GHSA-6v7p-g79w-8964, CVSS 3.1: 7.5 HIGH, CWE-416) affects
msgpack-python < 1.2.1: reusing an Unpacker after a previous unpack raised an
exception can resume from a corrupt parser context and crash the process with a
SEGV (denial of service). It was fixed upstream in msgpack 1.2.1 via commit
2c56ddb.

srsly vendors this code as srsly/msgpack/unpack_template.h and
srsly/msgpack/_unpacker.pyx. I checked the 2.5.3 sdist, and the vulnerable
pattern is present — the fork is in fact missing cleanup that even pre-patch
upstream had:

• srsly/msgpack/unpack_template.h — the vendored unpack_clear only clears
  stack[0].obj; it does not walk the stack or re-init the context:

  static inline void unpack_clear(unpack_context *ctx)
  {
      Py_CLEAR(ctx->stack[0].obj);
  }

  The 1.2.1 fix adds unpack_init(ctx) here, clears map keys across the whole
  stack, and calls unpack_clear() from unpack_construct / unpack_skip on the
  error (-1) return. srsly's unpack_construct / unpack_skip return the raw
  execute result with no cleanup.

• srsly/msgpack/_unpacker.pyx — the Unpacker._unpack error branch raises
  FormatError / StackError / ValueError but never calls
  unpack_clear / unpack_init on self.ctx, so the next unpack() / skip()
  resumes from the corrupt context.

Impact

• SCA tools that do source-file hashing (Mend/WhiteSource in our case) flag srsly
  itself against CVE-2026-57585 via the vendored files, with no upgrade path to
  clear the finding — msgpack is bundled, not a declared dependency, so upgrading
  the standalone msgpack package does nothing.
• srsly's own high-level helpers (msgpack_loads, etc.) create a fresh unpacker
  per call, so the vulnerable reuse-after-error pattern is not reachable through
  the documented API. But any code that instantiates srsly.msgpack.Unpacker
  directly and reuses it across a caught error is exposed, and the flagged code
  ships in the compiled wheel regardless.

Request

Re-vendor msgpack with the 1.2.1 fix, or cherry-pick the relevant parts of commit
2c56ddb into the fork (the changes are in unpack_template.h and
_unpacker.pyx), and cut a release. Happy to test a build.

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-57585
• GHSA-6v7p-g79w-8964
• msgpack/msgpack-python@2c56ddb
• https://github.com/msgpack/msgpack-python/releases/tag/v1.2.1