fix(rust): Zero vtable memory in write_vtable to prevent uninitialize…#8898
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
I don't think any of our other tests are written in source -- is there a way to test this from the tests directory? Or do you need intimate access to create the allocator? I am not a rust person :) |
|
I barely know Rust either. This is just the way I've seen it done. I'm sure I can follow the pattern of the others if needed. |
…d data The write_vtable() function's comment claimed to "fill the WIP vtable with zeros" but make_space() only reserves memory without initializing it. When using custom allocators with non-zeroed buffers, unset vtable field entries would contain garbage instead of zero (which indicates "use default value"). This fix explicitly zeros the vtable memory after reserving space, matching the C++ implementation's buf_.fill_big() behavior. Added regression test using a garbage-filled allocator (0xAA) that verifies vtable entries for unset fields are properly zeroed. Fixes google#8894
248e3c7 to
abbe488
Compare
|
I think that resolves it. |
Now that tat is fixed, let me know if there is anything else I need to do. |
Summary
Fixes #8894
The
write_vtable()function's comment claimed to "fill the WIP vtable with zeros" butmake_space()only reserves memory without initializing it. When using custom allocators with non-zeroed buffers, unset vtable field entries would contain garbage instead of zero (which indicates "use default value").Changes:
buf_.fill_big()behaviorTest plan
test_vtable_zeroed_with_garbage_allocatoradded