In compact block opportunistic reconstruction we have a comment above the MarkBlockAsReceived call:

                // Clear download state for this block, which is in
                // process from some other peer.  We do this after calling
                // ProcessNewBlock so that a malleated cmpctblock announcement
                // can't be used to interfere with block relay.

That's great and all, but we don't have anything similar in ::BLOCK handling. Thus, if you have a compact block blocktxn request in-flight from one peer, another peer can send you a malleated block as a regular block message causing the in-flight state to be cleared. That peer will get banned, so its a one-time block propagation slowdown (and shouldn't even be all that much of a slowdown), but worth noting. Writing it up primarily cause it should be considered in some eventual in-flight-blocks refactoring in conjunction with a #10984 rebase.