x/vulndb: potential Go vuln in github.com/ethereum/go-ethereum/core: GHSA-xw37-57qp-9mm4

[GoVulnBot]

In GitHub Security Advisory GHSA-xw37-57qp-9mm4, there is a vulnerability in the following Go packages or modules:

Unit	Fixed	Vulnerable Ranges
github.com/ethereum/go-ethereum/core	1.9.20	>= 1.9.4, < 1.9.20

Cross references:

• CVE-2020-26265 appears in issue dummy issue #105
• GHSA-xw37-57qp-9mm4 appears in issue dummy issue #105

See doc/triage.md for instructions on how to triage this report.

modules:
  - module: TODO
    versions:
      - introduced: 1.9.4
        fixed: 1.9.20
    packages:
      - package: github.com/ethereum/go-ethereum/core
  - module: TODO
    versions:
      - fixed: 1.9.20
    packages:
      - package: github.com/ethereum/go-ethereum
description: "### Impact\n\nA consensus-vulnerability in Geth could cause a chain
    split, where vulnerable versions refuse to accept the canonical chain. \n\n###
    Description\n\n\nA flaw was repoted at 2020-08-11 by John Youngseok Yang (Software
    Platform Lab), where a particular sequence of transactions could cause a consensus
    failure.\n\n- Tx 1:\n  - `sender` invokes `caller`.\n  - `caller` invokes `0xaa`.
    `0xaa` has 3 wei, does a self-destruct-to-self\n  - `caller` does a  `1 wei` -call
    to `0xaa`, who thereby has 1 wei (the code in `0xaa` still executed, since the
    tx is still ongoing, but doesn't redo the selfdestruct, it takes a different path
    if callvalue is non-zero)\n\n- Tx 2:\n  - `sender` does a 5-wei call to 0xaa.
    No exec (since no code). \n\nIn geth, the result would be that `0xaa` had `6 wei`,
    whereas OE reported (correctly) `5` wei. Furthermore, in geth, if the second tx
    was not executed, the `0xaa` would be destructed, resulting in `0 wei`. Thus obviously
    wrong. \n\nIt was determined that the root cause was this [commit](https://github.com/ethereum/go-ethereum/commit/223b950944f494a5b4e0957fd9f92c48b09037ad)
    from [this PR](https://github.com/ethereum/go-ethereum/pull/19953). The semantics
    of `createObject` was subtly changd, into returning a non-nil object (with `deleted=true`)
    where it previously did not if the account had been destructed. This return value
    caused the new object to inherit the old `balance`:\n\n```golang\nfunc (s *StateDB)
    CreateAccount(addr common.Address) {\n\tnewObj, prev := s.createObject(addr)\n\tif
    prev != nil {\n\t\tnewObj.setBalance(prev.data.Balance)\n\t}\n}\n```\n\nIt was
    determined that the minimal possible correct fix was\n\n```diff\n+++ b/core/state/statedb.go\n@@
    -589,7 +589,10 @@ func (s *StateDB) createObject(addr common.Address) (newobj,
    prev *stateObject)\n                s.journal.append(resetObjectChange{prev: prev,
    prevdestruct: prevdestruct})\n        }\n        s.setStateObject(newobj)\n-       return
    newobj, prev\n+       if prev != nil && !prev.deleted {\n+               return
    newobj, prev\n+       }\n+       return newobj, nil\n```\n\n### Patches\n\nSee
    above. The fix was included in Geth `v1.9.20` \"Paragade\".\n\n### Credits\n\nThe
    bug was found by @johnyangk and reported via bounty@ethereum.org.\n\n### For more
    information\nIf you have any questions or comments about this advisory:\n* Open
    an issue in [go-ethereum](https://github.com/ethereum/go-ethereum)\n* Email us
    at [security@ethereum.org](mailto:security@ethereum.org)"
cves:
  - CVE-2020-26265
ghsas:
  - GHSA-xw37-57qp-9mm4

[tatianab]

Duplicate of #105