-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8 bytes written into heap buffer of size 4 #11421
Comments
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight. |
Hello, @paulb777 ! I was wondering if there might be an update available regarding the resolution of this issue. Do you need any additional information to facilitate the investigation and rectification of the bug? Thank you for your time and effort. |
Thank you @mstyura for the thorough report. It'll take some time for us to look into this issue and fully test a fix. Unfortunately, the fix won't make it into our July release. |
Firebase 10.13.0 includes the fix for this. Please reopen this ticket if the issue still occurs in 10.13.0 or later. |
Description
TLDR: 4 bytes buffer allocated from
apmpb_copy_measurement_bundle + 1900
is being written 8 bytes usingnano_set_uint32
fromAPMUpdateConsentSignalsAndIdentifiers + 236
Full description:
Here is more detailed steps how corruption happen:
apmpb_copy_measurement_bundle + 1900
:backtrace of 4 bytes block allocation:
at that point write watchpoint is added for memory location $x0+4 (outside of the buffer)
nano_set_uint32
called fromAPMUpdateConsentSignalsAndIdentifiers + 236
via intermediate call toNANOSetInt32 + 140
:backtrace of 8 bytes write to 4 byte buffer:
The suspicious thing is that
nano_set_uint32
could allocate buffer by itself, but it uses8
bytes as buffer size, so it is likely that provided buffer must be at least8
bytes:It is interesting why function which has
uint32
in name does allocate8
bytes, instead of intuitevely guessable4
bytes.It also interesting why it does
8
bytes-wide write while function name suggest 32-bit wide argument.Here is the disassembly of provided by lldb:
Using
godbolt.org
I've reconstructed the possible definitioon ofnano_set_uint32
in C language:such that generated assembly by clang 16 with -O2 optimization produces almost the same assembly with the difference in one instruction which I believe effectively does the same thing - 64-bit to 32-bit integer truncation:
There is obviously something wrong here, either
apmpb_copy_measurement_bundle
should allocate larger buffer ornano_set_uint32
should not do 8 bytes write.It also seems that somewhere (silent?) conversion from uint32_t* to uint64_t* done, leading to buffer overflow later.
Could you please inspect related part of Firebase SDK source code and fix buffer overflow problem?
This issue is probably harmful due to smallest
malloc
block allocated on iOS is actually 16 bytes, but this overrun mess with runtime diagnostic tools, in my casemimalloc
with debug checks enabled.Reproducing the issue
Use Firebase SDK in such a way that it uploads data to it's server.
Firebase SDK Version
10.10.0
Xcode Version
14.3.1
Installation Method
Swift Package Manager
Firebase Product(s)
All
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved
No response
If using CocoaPods, the project's Podfile.lock
No response
The text was updated successfully, but these errors were encountered: