-
Notifications
You must be signed in to change notification settings - Fork 272
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
GraphicBuffer unflatten test does not detect patched Kitkat #97
Comments
This issue was reported in #21 . It was supposedly fixed there. Can you show which device you are using and possibly your code with the patch applied? |
Thanks for your reply. The device is a nexus 5 and this is my patched unflatten code: status_t GraphicBuffer::unflatten(
} |
Running VTS on KTU84P 4.4.4_r1 shows that unflatten is still unpatched even though the patch has been applied (as well as the CVE-2015-1528 patch).
Assuming I did not miss anything....
According to VTS code, the test seems to rely on the unflatten() return value, and expects patched code to return BAD_VALUE, but the test uses values that do not trigger the code that returns BAD_VALUE.
Even more so, the values given (r1[6] = 0x1000, r1[7] = 0xFF5, r2[0] = 0x20) result in (size < sizeNeeded) which returns NO_MEMORY, in both patched and unpatched code.
It almost seems as if the values of 0x1000 and 0xFF5 have been selected to test for the patch section that handles native_handle_create's failure (by triggering the CVE-2015-1528 patch), but that code also returns NO_MEMORY, which would still give the indication that the code is unpatched.
IMHO, r1[6], r1[7] and r2[0] values should be changed to (UINT_MAX / sizeof(int)) which should trigger the patched BAD_VALUE return code.
The other option would be to set r2[0] to be larger than 0x1000, but then the patched code would return NO_MEMORY, and unpached code would crash.
HTH.
The text was updated successfully, but these errors were encountered: