Yeah, it could be that both discovered the vulnerability independently. It's just that, from a timing perspective, Ludwig found it first, and provided explanations which where accessible and readable to all on the public board. It doesn't necessarily mean that Bailey read them and appropriate them.
Current kernel users : zRam, SquashFS, BTRFS, BootLoader
First 3 use small block sizes, KB range.
Last one used the LZ4 file format, which limits blocks to 8 MB.
Yes, there is no kernel program at risk right now, but it's nonetheless good to plug the vulnerability, in anticipation for future usages.
In my view, this does not deserve headlines. Instead, we should be happy to have software coders fixing problems even before they get a chance to happen.
Of course, this argument is totally nuts. 2^64 of RAM is not accessible, period. It's ludicrous to pretend that a code delivered today should take into consideration a potential issue that might happen in 30 years from now. Frankly, you expect the code to no longer be updated that long and still be used ??
The LZ4 Memory corruption was already fully described at the LZ4 issue board, and accepted by the LZ4 author. What is this article supposed to learn us ?
This reminds me of this game for HP48. It had some pretty graphics for the time, using 4-grey colors with LCD timing tricks.
Unfortunately, it also meant the game was heavy (40KB!). And even more unfortunately, some HP48 emulators (most importantly the Android ones) do not support 4-grey graphics, making the game unusable... :(
