lru: add advisory for Stacked Borrows violation

[paolobarbolini]

Adds the advisory for jeromefroe/lru-rs#224.

@jeromefroe let us know if you are ok with this.

[alamb]

Can someone please update the advisory to explain more about what the impact of the issue to help downstream users evaluate if they are affected by the issue? Specifically, the PR jeromefroe/lru-rs#224 says

This invalidates the pointer held within KeyWrapper by the HashMap, but the HashMap still holds and accesses it on subsequent reads or writes to the LRU, which is unsound.

What possible exploit / corruption is possible due to this unsoundness? The PR points that MIRI calls out a potential issue, but the implications are hard to understand.

Is the idea that anything using IterMut on an LRU cache to iterate and mutate the contents can cause memory corruption?

[paolobarbolini]

AFAIK (not a Stacked Borrows expert) on current compilers this should not lead to UB, which is why I marked it as informational = "unsound".

[alamb]

AFAIK (not a Stacked Borrows expert) on current compilers this should not lead to UB, which is why I marked it as informational = "unsound".

I see -- if that is the case, then I think this is another example of contributing to a low signal to noise ration in the advisory database:

• Discussion: signal/noise ratio too low? #2572