Upstream patch:
http://lists.helixcommunity.org/pipermail/filesystem-cvs/2008-January/000676.html
https://helixcommunity.org/viewcvs/filesystem/http/httpfsys.cpp?view=log#rev1.113

According to upstream, this issue does affect Helix Player 1.x.

Patch changes the code to use strtol instead of the strtoul and checks whether the value returned is not negative.  When using strtoul, pChunkedEncoding->size can be set to ULONG_MAX and can lead to integer overflow / insufficient buffer allocation in:
  pChunkedEncoding->buf = new char[pChunkedEncoding->size + 1];

1.0.x versions of Helix Player including the latest one - 1.0.9 - available from the upstream download page does, however, still use strtol and uses signed long for the size member of the HTTPChunkedEncoding.  Change to unsigned long / strtoul was only introduced after 1.0.9.

With signed type, size can be LONG_MAX at max, which does not lead to an integer overflow when 1 is added to it.  Negative size is also caught and results in error return code from CHTTPFileObject::DecodeChunkedEncoding.  The code in 1.0.x looks as:

  pChunkedEncoding->size = strtol(pChunkedEncoding->buf, &errstr, 16);
  if (pChunkedEncoding->size > 0) {
    /* allocate / memset memory */
  } else if (pChunkedEncoding->size == 0) {
    /* end of chunk header, change state to "expecting chunk body" */
  } else {
    rc = HXR_FAILED;
    break;
  }