Linux is beautifully optimised for performance. Linux is more likely to write the same data more quickly than Windows, when an application has a large amount of data to write. So if the problem is the SSD fails when a large amount of data is written quickly but within specs, then it's likely to fail on Linux too.
Unless it's a bug in the Windows driver. But it sounds from descriptions that it isn't a bug in Windows, it's a bug in the SSD that went unnoticed because not many people wrote large amounts of data quickly on systems with those SSDs.
So it sounds like there may be a model-specific blacklist required in the driver, to detect particular SSDs and reduce the speed they are written to, because they fail when run at the speed they advertise to the OS.
Or, alternatively, it sounds like those models may require a firmware upgrade from the SSD vendor.
If either of those are required, a similar workaround will be required in the Linux driver too, to avoid the same problem as soon as someone runs a similar application on Linux.
Unfortunately, even with a speed-limiting blacklist in the driver, whether in Window or Linux, those SSD models probably still corrupt data from time to time, because speed alone is unlikely to be the underlying cause of corruption. A vendor firmware update, or vendor confirmation that a specific change in the driver avoids the SSD bug, are what's required.