How does copying main stack prevent malformed unlocking scripts vulnerabilities? https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc


  In the original bitcoin client, the unlocking and locking scripts were
  concatenated and executed in sequence. For security reasons, this was
  changed in 2010, because of a vulnerability that allowed a malformed
  unlocking script to push data onto the stack and corrupt the locking
  script. In the current implementation, the scripts are executed
  separately with the stack transferred between the two executions, as
  described next.
  
  First, the unlocking script is executed, using the stack execution
  engine. If the unlocking script is executed without errors (e.g., it
  has no "dangling" operators left over), the main stack is copied and
  the locking script is executed. If the result of executing the locking
  script with the stack data copied from the unlocking script is "TRUE,"
  the unlocking script has succeeded in resolving the conditions imposed
  by the locking script and, therefore, the input is a valid
  authorization to spend the UTXO.


In this chapter, Andreas states that due to a bug with malformed unlocking scripts, the scripts are now executed separately.

Here is my understanding:

The unlocking script is first executed on the main stack.
If the unlocking script is valid, the entire stack is copied and the locking script is then executed.

Is there a reason why the stack is not copied to an alternate stack and then the unlocking script is executed on the alt stack? This way, if the unlocking script is malformed, it would not corrupt the rest of the main stack.
you can find explanation here:
https://bitcointalk.org/index.php?topic=5095376.msg49150302#msg49150302


  the issue was actually with OP_RETURN. What OP_RETURN used to do is it would skip to the end of the script so whatever was on the stack was interpreted for the final script result. So what you could do was create a scriptSig that was just


OP_TRUE OP_RETURN



  which would push true to the stack and skip the rest of the script (which included the scriptPubKey at this time). The interpreter would see that at the end of script execution a true was left on the stack so it would say that the script passed. Obviously this is bad because the nothing in the scriptPubKey was evaluated so none of the spending conditions were actually met.
  
  In fixing this bug, Satoshi disabled many other opcodes, changed OP_RETURN to always cause script execution to fail, and separated the execution of the scriptSig and the scriptPubKey so that the scriptPubKey is always executed.