To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.
For Variant 1, the "vulnerable code pattern" they're looking for has to be of a very specific type, it's not a run-of-the-mill gadget. It has to load from an array with a user-controlled offset, then mask out a small number of bits from the result and use that as an offset to load from another array, where we can then time our accesses to that second array.
However, they also go on to say:
A minor variant of this could be to instead use an out-of-bounds read to a function pointer to gain control of execution in the mis-speculated path. We did not investigate this variant further.
Which seems much less reassuring.
