Verified
Status Update
Comments
[Deleted User] <[Deleted User]> #2
Setting milestone and target because of medium severity.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
ha...@google.com <ha...@google.com> #3
[Empty comment from Monorail migration]
me...@chromium.org <me...@chromium.org> #4
drott: Could you please take a look at this freetype issue? Thanks.
[Monorail components: Blink>Fonts]
[Monorail components: Blink>Fonts]
dr...@chromium.org <dr...@chromium.org> #5
Reducing priority based on security impact medium, seems like the fuzzer found another way to trigger in this function, similar to https://crbug.com/chromium/1505216 .
[Deleted User] <[Deleted User]> #6
Setting Pri-1 to match security severity Medium. If this is incorrect, please reset the priority. Sheriffbot won't make this change again.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
is...@google.com <is...@google.com> #7
This issue was migrated from crbug.com/chromium/1522492?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
pe...@google.com <pe...@google.com> #8
drott: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.
pe...@google.com <pe...@google.com> #9
drott: Uh oh! This issue still open and hasn't been updated in the last 29 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add Disable-Nags (case sensitive) to the Chromium Labels custom field.
bu...@chromium.org <bu...@chromium.org> #10
I am finally able to reproduce this. Fortunately the minimal reproducer data is straight font data, however this does require a 32 bit build with AddressSanitizer, which is a bit interesting. Managed to do this by building Skia with gcc and libstdc++ instead of clang and libc++, as debian is currently making setting up the latter rather difficult.
bu...@chromium.org <bu...@chromium.org> #11
The issue is that in this instance `num_base_glyphs_v1 = 2147483648` which causes interesting wrap around in 32 bit builds. This should be caught by checks in `tt_face_load_colr` but isn't due to wrap around issues there. Unfortunately I reproduced on an AMD machine that doesn't support `rr` very well.
bu...@chromium.org <bu...@chromium.org> #12
In tt_face_load_colr
num_base_glyphs_v1 = 2147483648
, base_glyphs_offset_v1 = 34
, table_size = 174
, and BASE_GLYPH_PAINT_RECORD_SIZE
is defined to be 6U
. As a result num_base_glyphs_v1 * BASE_GLYPH_PAINT_RECORD_SIZE
overflows to 0, which is less than the size of the space available.
bu...@chromium.org <bu...@chromium.org> #13
There are numerous versions of this here, where there is "read a value, multiply it by some constant without checking for overflow, then compare against some range". All of these need to be fixed.
bu...@chromium.org <bu...@chromium.org> #14
Fixing these appears to fix both this issue and
24...@project.gserviceaccount.com <24...@project.gserviceaccount.com> #17
ClusterFuzz testcase 5039808033783808 is verified as fixed in https://clusterfuzz.com/revisions?job=x86_libfuzzer_chrome_asan&range=1298122:1298149
If this is incorrect, please add the hotlistid:5432646 and re-open the issue.
If this is incorrect, please add the hotlistid:5432646 and re-open the issue.
bu...@chromium.org <bu...@chromium.org>
pe...@google.com <pe...@google.com> #18
This bug has been closed for more than 14 weeks. Removing issue access restrictions.
Description
Fuzzing Engine: libFuzzer
Fuzz Target: open_type_math_support_fuzzer
Job Type: x86_libfuzzer_chrome_asan
Platform Id: linux
Crash Type: UNKNOWN READ
Crash Address: 0x06a06786
Crash State:
tt_face_get_colr_glyph_paint
FT_Get_Color_Glyph_Paint
SkScalerContext_FreeType::generateMetrics
Sanitizer: address (ASAN)
Recommended Security Severity: Medium
Regressed:
Reproducer Testcase:
Issue filed automatically.
See