summaryrefslogtreecommitdiff
path: root/Documentation/admin-guide
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2022-04-18 20:57:31 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-05-30 09:33:40 +0200
commit9dff512945f19afc91515f7b4e0ffe06fab417ed (patch)
treed20d3acc52df6cedfd3320302a9045d6ec0b141b /Documentation/admin-guide
parenta1b5c849d855c97f75375c564321961ad18b8f46 (diff)
downloadlinux-9dff512945f19afc91515f7b4e0ffe06fab417ed.tar.gz
linux-9dff512945f19afc91515f7b4e0ffe06fab417ed.tar.bz2
linux-9dff512945f19afc91515f7b4e0ffe06fab417ed.zip
random: document crng_fast_key_erasure() destination possibility
commit 8717627d6ac53251ee012c3c7aca392f29f38a42 upstream. This reverts 35a33ff3807d ("random: use memmove instead of memcpy for remaining 32 bytes"), which was made on a totally bogus basis. The thing it was worried about overlapping came from the stack, not from one of its arguments, as Eric pointed out. But the fact that this confusion even happened draws attention to the fact that it's a bit non-obvious that the random_data parameter can alias chacha_state, and in fact should do so when the caller can't rely on the stack being cleared in a timely manner. So this commit documents that. Reported-by: Eric Biggers <ebiggers@kernel.org> Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/admin-guide')
0 files changed, 0 insertions, 0 deletions