)]}'
{
  "commit": "204dea8daeee9935b2b08da2c2dfe7b890ed36a7",
  "tree": "23a570186fb8e29e109b04ea4419999e8eb5abdb",
  "parents": [
    "a43fd90c5ddd85604f308d1664e8f2cedca28b92"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Tue May 03 07:42:19 2016 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Tue May 03 16:43:12 2016 +0000"
  },
  "message": "Fix encrypt overflow\n\nAn overflow can occur in the EVP_EncryptUpdate function. If an attacker is\nable to supply very large amounts of input data after a previous call to\nEVP_EncryptUpdate with a partial block then a length check can overflow\nresulting in a heap corruption.\n\nFollowing an analysis of all OpenSSL internal usage of the\nEVP_EncryptUpdate function all usage is one of two forms.\n\nThe first form is like this:\nEVP_EncryptInit()\nEVP_EncryptUpdate()\n\ni.e. where the EVP_EncryptUpdate() call is known to be the first called\nfunction after an EVP_EncryptInit(), and therefore that specific call\nmust be safe.\n\nThe second form is where the length passed to EVP_EncryptUpdate() can be seen\nfrom the code to be some small value and therefore there is no possibility of\nan overflow. [BoringSSL: We also have code that calls EVP_CIPHER functions by\nway of the TLS/SSL3 \"AEADs\". However, there we know the inputs are bounded by\n2^16.]\n\nSince all instances are one of these two forms, I believe that there can\nbe no overflows in internal code due to this problem.\n\nIt should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate()\nin certain code paths. Also EVP_CipherUpdate() is a synonym for\nEVP_EncryptUpdate(). Therefore I have checked all instances of these\ncalls too, and came to the same conclusion, i.e. there are no instances\nin internal usage where an overflow could occur.\n\nThis could still represent a security issue for end user code that calls\nthis function directly.\n\nCVE-2016-2106\n\nIssue reported by Guido Vranken.\n\n(Imported from upstream\u0027s 3ab937bc440371fbbe74318ce494ba95021f850a.)\n\nChange-Id: Iabde896555c39899c7f0f6baf7a163a7b3c2f3d6\nReviewed-on: https://boringssl-review.googlesource.com/7845\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "341516a705e6108d35b17e1fc49a91ba5609e401",
      "old_mode": 33188,
      "old_path": "crypto/cipher/cipher.c",
      "new_id": "f61c59f4fece50875d1d75852aa15fb562f56b35",
      "new_mode": 33188,
      "new_path": "crypto/cipher/cipher.c"
    }
  ]
}