I would say its pretty detailed -an unknown interference caused a single crc protected 32 bit word to be corrupted simultaneously, by timestamp, in both the flight controller hardware and the black box data recorder.

My concern would be what error correction mechanism did or did not catch the corruption in memory and why did it not recover without critical impact to operations?

My guess is they haven't managed to point to the single memory bit which was flipped to cause this result.

The software update is probably more along the lines of 'lets just introduce a watchdog task which resets the system if the output deviates too far from the input for too long'.

Reading the Airbus press release, I wonder if this is what happened:

Solar radiation event led to alpha particle induced data corruption in a flight control computer memory (could be DRAM, SRAM, on-chip cache, registers...). These failures are supposed to be transient (reboot and all is well).

This is an anticipated failure mode. Only one (of three?) computers should be affected by such a failure and therefore the remaining two keep on running the plane.

But what happened is <something> went wrong with the failover/voting mechanism (as often happens with one-off seldom-executed failover code). The result was no flight control computer functionality until the entire system was rebooted. Hence the emergency landing.

The fix is to address that software error, with perhaps a secondary fix TBD to harden the hardware (add some shielding perhaps).

The fact that they talk about data corruption and not just a malfunction suggests alpha bit flip rather than latch-up.

Then send the whole statement through a French to English translator to make it a bit more confusing.