)]}'
{
  "commit": "04dd34c14ed21d36e80447dd988fa1ce4ebe5ac5",
  "tree": "bc84a46ac59be606baf64a6a23a0d3986b2c3aa6",
  "parents": [
    "3ee3d8799ae346fbf3c1e6fd15dbc1593545fa80"
  ],
  "author": {
    "name": "DRC",
    "email": "information@libjpeg-turbo.org",
    "time": "Thu Feb 04 10:59:21 2016 -0600"
  },
  "committer": {
    "name": "DRC",
    "email": "information@libjpeg-turbo.org",
    "time": "Thu Feb 04 11:37:13 2016 -0600"
  },
  "message": "Guard against wrap-around in alloc functions\n\nBecause of the exposed nature of the libjpeg API, alloc_small() and\nalloc_large() can potentially be called by external code.  If an\napplication were to call either of those functions with\nsizeofobject \u003e SIZE_MAX - ALIGN_SIZE - 1, then the math in\nround_up_pow2() would wrap around to zero, causing that function to\nreturn a small value.  That value would likely not exceed\nMAX_ALLOC_CHUNK, so the subsequent size checks in alloc_small() and\nalloc_large() would not catch the error.\n\nA similar problem could occur in 32-bit builds if alloc_sarray() were\ncalled with\nsamplesperrow \u003e SIZE_MAX - (2 * ALIGN_SIZE / sizeof(JSAMPLE)) - 1\n\nThis patch simply ensures that the size argument to the alloc_*()\nfunctions will never exceed MAX_ALLOC_CHUNK (1 billion).  If it did,\nthen subsequent size checks would eventually catch that error, so we\nare instead catching the error before round_up_pow2() is called.\n\nThis addresses a minor concern (LJT-01-001) expressed in a security\naudit by Cure53.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5fbebb4b12cbf474483b24d7a8122618a25720db",
      "old_mode": 33188,
      "old_path": "jmemmgr.c",
      "new_id": "4b0fcac01fd250b784d9eb9247932f085100d870",
      "new_mode": 33188,
      "new_path": "jmemmgr.c"
    }
  ]
}