)]}'
{
  "commit": "7e18ca8cc99541acbb614c19ae34a1d7790e3fce",
  "tree": "7675e8ed8f2f001fb34c1b410a97218601be5244",
  "parents": [
    "2c84a0e101cb08a9554743f0a6f7777b95978026"
  ],
  "author": {
    "name": "Maxim Dounin",
    "email": "mdounin@mdounin.ru",
    "time": "Tue Jul 11 16:06:23 2017 +0300"
  },
  "committer": {
    "name": "Maxim Dounin",
    "email": "mdounin@mdounin.ru",
    "time": "Tue Jul 11 16:06:23 2017 +0300"
  },
  "message": "Range filter: protect from total size overflows.\n\nThe overflow can be used to circumvent the restriction on total size of\nranges introduced in c2a91088b0c0 (1.1.2).  Additionally, overflow\nallows producing ranges with negative start (such ranges can be created\nby using a suffix, \"bytes\u003d-100\"; normally this results in 200 due to\nthe total size check).  These can result in the following errors in logs:\n\n[crit] ... pread() ... failed (22: Invalid argument)\n[alert] ... sendfile() failed (22: Invalid argument)\n\nWhen using cache, it can be also used to reveal cache file header.\nIt is believed that there are no other negative effects, at least with\nstandard nginx modules.\n\nIn theory, this can also result in memory disclosure and/or segmentation\nfaults if multiple ranges are allowed, and the response is returned in a\nsingle in-memory buffer.  This never happens with standard nginx modules\nthough, as well as known 3rd party modules.\n\nFix is to properly protect from possible overflow when incrementing size.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7ad9db9dd2bb49738d8003e8aa4d22f9b93ba689",
      "old_mode": 33188,
      "old_path": "src/http/modules/ngx_http_range_filter_module.c",
      "new_id": "ac910fdfed535d1638ef54720d33801bbd3ae0fb",
      "new_mode": 33188,
      "new_path": "src/http/modules/ngx_http_range_filter_module.c"
    }
  ]
}