Fix keccak bug

Changelog.md

@@ -1,5 +1,8 @@
 ### 0.8.3 (unreleased)
 
+Important Bugfixes:
+ * Optimizer: Fix bug on incorrect caching of Keccak-256 hashes.
+
 Language Features:
 
 

docs/bugs.json

@@ -1,4 +1,15 @@
 [
+    {
+        "name": "KeccakCaching",
+        "summary": "The bytecode optimizer incorrectly re-used previously evaluated Keccak-256 hashes. You are unlikely to be affected if you do not compute Keccak-256 hashes in inline assembly.",
+        "description": "Solidity's bytecode optimizer has a step that can compute Keccak-256 hashes, if the contents of the memory are known during compilation time. This step also has a mechanism to determine that two Keccak-256 hashes are equal even if the values in memory are not known during compile time. This mechanism had a bug where Keccak-256 of the same memory content, but different sizes were considered equal. More specifically, ``keccak256(mpos1, length1)`` and ``keccak256(mpos2, length2)`` in some cases were considered equal if ``length1`` and ``length2``, when rounded up to nearest multiple of 32 were the same, and when the memory contents at ``mpos1`` and ``mpos2`` can be deduced to be equal. You maybe affected if you compute multiple Keccak-256 hashes of the same content, but with different lengths inside inline assembly. You are unaffected if your code uses ``keccak256`` with a length that is not a compile-time constant or if it is always a multiple of 32.",
+        "link": "https://blog.soliditylang.org/2021/03/23/keccak-optimizer-bug/",
+        "fixed": "0.8.3",
+        "conditions": {
+            "optimizer": true
+        },
+        "severity": "medium"
+    },
     {
         "name": "EmptyByteArrayCopy",
         "summary": "Copying an empty byte array (or string) from memory or calldata to storage can result in data corruption if the target array's length is increased subsequently without storing new data.",