This article sounds bunk. The argument boils down to "because a security flaw is theoretically possible, we should consider it to be practically critical". Obv

This article sounds bunk. The argument boils down to "because a security flaw is theoretically possible, we should consider it to be practically critical". Obviously, that's nonsense. Assuming other analysis is correct suggesting that no vulnerable applications could be found, then there is no security flaw. LZ4 is not exploitable by itself; it is not a standalone application. Clearly, there's a bug. It's nice that it's fixed because it might have caused nasty problems in the future. By analogy; is C a security flaw because it is not memory safe? Clearly, usage of C can result in overflows and other memory corruption. Nevertheless, usage of C does not necessarily imply security flaws. It's nice (and important in the long run) that we can avoid certain risks by fixing bugs or design flaws in our tools, and many other languages attempt to by being (mostly) memory safe to avoid this class of risk. But, however important, that long-term improvement is not the same thing as a critical security flaw now.