Fix fuzzer bug with cmap4 #1101
Conversation
Is most of the size all in cmap or in other parts? If it's only cmap, not sure if it helps here, but @cmyr had a good suggestion on how to test per table only in #969 (comment) |
|
A significant portion is cmap, ttx -l reports cmap to be 73978 long. I think I might have to resort to mangling some bytes by hand when I have a free minute. |
rsheeter
force-pushed
the
fz3
branch
4 times, most recently
from
c291fa5 to
520c668
Compare
| // https://github.com/googlefonts/fontations/issues/1100 | ||
| // cmap4 ranges are u16 so no need to stress about values past char::MAX | ||
| self.cur_range = next_range.start.max(self.cur_range.end) | ||
| ..next_range.end.max(self.cur_range.end); | ||
| self.cur_start_code = self.cur_range.start as u16; |
There was a problem hiding this comment.
I'm not sure if it matters in broken fonts, but I think self.cur_start_code should still be set to next_range.start even if we chop up the range because the remainder of the encoded data is likely dependent on the original value.
There was a problem hiding this comment.
I see your point but also don't want to produce duplicate values. I'm a touch low on time so lets get the immediate fix landed and defer that part to a follow-on. Filed as #1175.
#954 (the same for cmap12) has raw bytes which are presumably the minimized test repro (?)
The fuzzer repro for this is 137K so we use hand-crafted data to demonstrate the Cmap4Iter used to be happy to reprocess codepoints.
IMHO the floor for the next range should be
cur_range.end + 1but this somehow breaks a klippa integrate test so I deferred that to #1166.Fixes #1100