Fix reinterpret_cast to a wrong storage size #21170
Conversation
This resolves cms-sw#21096 ASan reported stack-buffer-overflow read of 8 bytes in `std::hash_specialization<float>::operator()(std::tuple<float> const&)` We have a float (4 bytes) and we get a reference to it as `uint32_t` (4 bytes), but later we get another reference as `result_type` (`std::size_t`) which is 8 bytes. That's a different storage size. Thus we will be reading extra 4 bytes from the memory, which don't belong to the float. Instead now we properly cast the resulting `uint32_t` to `result_type`, which will not damange the number. In workflow 4000.0 step3 this function is triggered 893'957 times each time returning `c61c3c00` (hex), i.e. the same value. Before the fix numbers looked like: 358'361 7ff5c61c3c00 133'306 7fffc61c3c00 65'670 c61c3c00 38'466 c61c3c00c61c3c00 6'039 3f1a36e2c61c3c00 3'268 d5446cdcc61c3c00 696 12c61c3c00 306 3c21e3c5c61c3c00 305 bc40413ec61c3c00 305 4014b189c61c3c00 303 40157dd9c61c3c00 299 40140ebbc61c3c00 293 4014df30c61c3c00 293 401430f5c61c3c00 288 40164789c61c3c00 [..] As you can see we almost always had extra garbage from the memory. Only 65'670 out of 893'957 times function returned intended value. Signed-off-by: David Abdurachmanov <David.Abdurachmanov@cern.ch>
|
The code-checks are being triggered in jenkins. |
|
+code-checks |
|
A new Pull Request was created by @davidlt for master. It involves the following packages: CondFormats/JetMETObjects @ggovi, @cmsbuild, @monttj can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
|
The tests are being triggered in jenkins. |
|
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
merge |
This resolves #21096
ASan reported stack-buffer-overflow read of 8 bytes in
std::hash_specialization<float>::operator()(std::tuple<float> const&)We have a float (4 bytes) and we get a reference to it as
uint32_t(4bytes), but later we get another reference as
result_type(
std::size_t) which is 8 bytes. That's a different storage size. Thuswe will be reading extra 4 bytes from the memory, which don't belong to
the float.
Instead now we properly cast the resulting
uint32_ttoresult_type,which will not damange the number.
In workflow 4000.0 step3 this function is triggered 893'957 times each
time returning
c61c3c00(hex), i.e. the same value.Before the fix numbers looked like:
As you can see we almost always had extra garbage from the memory.
Only 65'670 out of 893'957 times function returned intended value.
Signed-off-by: David Abdurachmanov David.Abdurachmanov@cern.ch