RUSTSEC-2024-0408: Unsound usages of std::slice::from_raw_parts
#46
Comments
LykxSassinator
added a commit
to LykxSassinator/tikv
that referenced
this issue
Dec 5, 2024
Signed-off-by: lucasliang <[email protected]>
Merged
9 tasks
ti-chi-bot bot
pushed a commit
to tikv/tikv
that referenced
this issue
Dec 5, 2024
close rusticata/pcap-parser#46, fix rusticata/pcap-parser#46, ref #15990 upgrade pprof to 0.14 to fix rusticata/pcap-parser#46. Signed-off-by: lucasliang <[email protected]>
ti-chi-bot
pushed a commit
to ti-chi-bot/tikv
that referenced
this issue
Dec 9, 2024
fix rusticata/pcap-parser#46, close rusticata/pcap-parser#46, ref tikv#15990 Signed-off-by: ti-chi-bot <[email protected]>
9 tasks
ti-chi-bot
pushed a commit
to ti-chi-bot/tikv
that referenced
this issue
Dec 11, 2024
fix rusticata/pcap-parser#46, close rusticata/pcap-parser#46, ref tikv#15990 Signed-off-by: ti-chi-bot <[email protected]>
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
pprof0.13.0The library breaks the safety assumptions when using unsafe API
std::slice::from_raw_parts. First, when using the API in iterator implementation (TempFdArrayIterator.next), generic type could be any type, which would create and pass a misaligned pointer to the unsafe API. Second, when validating the address, the code passed the typec_void, which could also be any type, leading to potential uninitialized memory exposure.Two unsound usages here highlight the necessity for developers to perform type checks before doing type conversion with unsafe API.
The panic caused by the misalignment causes several downstream applications (e.g.,
greptimedb) to crash when usingpprof::report::ReportBuilder::build.This was patched in 0.14.0.
The developer also suggested moving to pprof2.
See advisory page for additional details.
The text was updated successfully, but these errors were encountered: