The first issue, is an incorrect computation in golang impacting go-ethereum. Its an interesting case, because a base computation might lead to some issues but it usually isn’t a security issue. Being in go-ethereum and really I think any sort of VM implementation it can have some significant impacts as the VM would become desynchronized from the rest of the ecosystem.

The issue comes with using copy(dst, src) when dst and src overlap. This would be an obvious bug in many use cases the reaching of that copy was a bit non-intuitive. Starting with calling a contract that is built in to go-ethereum that is implemented by dataCopy. It then uses scope.Memory.Set(offset, size, value) with a contract/attacker controlled offset and size to write the ret. This can lead to the copy over part of the memory ret points to. I’d recommend taking a look at the code in the article for a better walkthrough.

The second issue is a bit more interest, and has to do with when anonymous functions capture the variables from the parent scope. Basically, they demonstrate a case where a function is created inside a for-loop. The developer intending to capture the k value from the range used in the loop.

for _, k := range keys {
    m[k] = true
    cleanupFs = append(cleanupFs, func() {
        fmt.Println("deleting", k)
        delete(m, k)
    })
}

The intent being to call delete(m,k) inside the cleanup function. What happens though is the value of k refers to the parent scope, which means all the functions created in the loop point to the same k value. Its an interesting, and rather non-intuitive case that you should be on the look out for. I could see this popping up in real code, though they do not demonstrate it.