)]}'
{
  "commit": "b93f995081cc32e56071fef179161d2907d0491e",
  "tree": "c4a4a5ab3111109055ffac05634c2d298b44b4e9",
  "parents": [
    "a49139af77850d64d74f9ffe43cabe7aa4f19de0"
  ],
  "author": {
    "name": "Max Reitz",
    "email": "mreitz@redhat.com",
    "time": "Tue Apr 29 19:03:14 2014 +0200"
  },
  "committer": {
    "name": "Kevin Wolf",
    "email": "kwolf@redhat.com",
    "time": "Wed Apr 30 14:46:17 2014 +0200"
  },
  "message": "qcow2: Check min_size in qcow2_grow_l1_table()\n\nFirst, new_l1_size is an int64_t, whereas min_size is a uint64_t.\nTherefore, during the loop which adjusts new_l1_size until it equals or\nexceeds min_size, new_l1_size might overflow and become negative. The\ncomparison in the loop condition however will take it as an unsigned\nvalue (because min_size is unsigned) and therefore recognize it as\nexceeding min_size. Therefore, the loop is left with a negative\nnew_l1_size, which is not correct. This could be fixed by making\nnew_l1_size uint64_t.\n\nOn the other hand, however, by doing this, the while loop may take\nforever. If min_size is e.g. UINT64_MAX, it will take new_l1_size\nprobably multiple overflows to reach the exact same value (if it reaches\nit at all). Then, right after the loop, new_l1_size will be recognized\nas being too big anyway.\n\nBoth problems require a ridiculously high min_size value, which is very\nunlikely to occur; but both problems are also simply avoided by checking\nwhether min_size is sane before calculating new_l1_size (which should\nstill be checked separately, though).\n\nSigned-off-by: Max Reitz \u003cmreitz@redhat.com\u003e\nSigned-off-by: Kevin Wolf \u003ckwolf@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b746429def0c4de818cb1ec05677cbc51c13bd47",
      "old_mode": 33188,
      "old_path": "block/qcow2-cluster.c",
      "new_id": "76d2bcf63ad540288df623f683b03c100cda7a02",
      "new_mode": 33188,
      "new_path": "block/qcow2-cluster.c"
    }
  ]
}