The result of deactivation of a interface, to OSPF, would be whatever the "normal" OSPF response to that interface going down. What that response might be, depends on the kind of interface, and what's it's "doing" vis-a-vis with OSPF. I.e. it matters not why the interface goes down, as far as OSPF is concerned, just that interface is down.
You also mention "repeated on all routers". Well, besides a down interface blocking (or black holing) traffic, this happening to many routers in a short time period, or even one router's OSPF interface, e.g. "flapping", for whatever reason, can cause some implementations of OSPF to "meltdown", as the routers are unable to keep up with all the topology changes. Cisco's implementation has special OSPF timers that delay processing the topology changes, longer and longer, if there appears to be instability in the topology. This to try to avoid OSPF, on all routers, going into "meltdown", but it may not mitigate the issue of trying to forward traffic on the particular interface(s) going down.
Besides what Cisco's OSPF implementation does, there's often other Cisco features to mitigate the impact of a "flapping" interface. Further, on later Cisco OSPF implementations, they have an OSPF feature to only recompute the part of the topology impacted by the change in link status.
Lastly, a "correctly" hardened Cisco network device, would make it difficult for an attacker to deactivate a network interface.
