Looking at the slides from a different article, these are not really in the chip per say but in the SDK. So any lib compiled to use the chip would be affected but not really a hardware issue. Basically fuzzy testing found 400 library calls that fail with segfaults. These can sometimes (but not always) be modified to do a takeover, but I didn't see anyone claiming to have done that.
It's even more intentionally misleading than that. The SDK generates wrapper libraries that allow you to interface with your code running on the DSP. Some of the wrapper functions generated have vulnerabilities. The 400 vulnerabilities are the few vulnerabilities found in the SDK template multiplied by how many different generated wrapper libraries they found.
So you fix the handful of errors in the SDK templates and all the 400 vulnerabilities go away.
