security: Add max_length to zlib.decompress in uworker_io.py to prevent decompression bomb DoS

[prasanna8585]

Summary

uworker_io.py calls zlib.decompress() three times without a max_length limit. A compromised or malicious uworker process could upload a small zlib-compressed bomb (~4 MB) to its signed GCS output URL, causing the trusted tworker to exhaust memory when decompressing, crashing the orchestrator.

The code already acknowledges the trust boundary:

# ...make sure we can infer the actual input since the output is not trusted.

But the decompression step had no corresponding size guard.

Changes

• Add _MAX_UWORKER_MSG_SIZE = 256 * 1024 * 1024 constant (256 MB)
• Apply max_length=_MAX_UWORKER_MSG_SIZE to all three zlib.decompress() calls:
  • download_and_deserialize_uworker_input() (line 129)
  • download_input_based_on_output_url() (line 170)
  • download_and_deserialize_uworker_output() (line 184)

The existing except zlib.error blocks already handle decompression failures gracefully — no additional error handling is required.

Attack Scenario

# Inside a compromised uworker:
import zlib, requests
bomb = zlib.compress(b'\x00' * (4 * 1024 * 1024 * 1024), level=1)  # ~4MB → 4GB
requests.put(signed_upload_url, data=bomb)
# tworker calls zlib.decompress(bomb) → OOM crash

Fix Verification

After this patch, zlib.decompress(data, max_length=_MAX_UWORKER_MSG_SIZE) raises zlib.error if the decompressed output exceeds 256 MB. The caller's existing except zlib.error block handles this as a backward-compatibility fallback, so no disruption to normal operation.