walkero
/
harfbuzz
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Drop layout table if layout lookup accelerator allocation failed 

If the table is kept, when the table is present but only the accelerator
allocation failed, then we run into nullptr dereferences downstream in
hb_ot_map_t::apply when trying to access proxy.accels[i].

To fix this, instead of only setting lookup_count of accelerator_t
itself, drop the whole table to avoid hb-ot-map construction assuming
that the lookups will work correctly despite accelerator allocation
having failed.

Fixes:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24490
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24490
This commit is contained in:
Dominik Röttsches 2020-10-23 14:25:05 +03:00 committed by Behdad Esfahbod
parent b2e7bb2a7c
commit a5f6f869e8
1 changed files with 4 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/hb-ot-layout-gsubgpos.hh
View File

@ -3378,7 +3378,11 @@ struct GSUBGPOS
this->accels = (hb_ot_layout_lookup_accelerator_t *) calloc (this->lookup_count, sizeof (hb_ot_layout_lookup_accelerator_t)); this->accels = (hb_ot_layout_lookup_accelerator_t *) calloc (this->lookup_count, sizeof (hb_ot_layout_lookup_accelerator_t));
if (unlikely (!this->accels)) if (unlikely (!this->accels))
{
this->lookup_count = 0; this->lookup_count = 0;
hb_blob_destroy (this->table.get_blob ());
this->table = hb_blob_get_empty ();
}
for (unsigned int i = 0; i < this->lookup_count; i++) for (unsigned int i = 0; i < this->lookup_count; i++)
this->accels[i].init (table->get_lookup (i)); this->accels[i].init (table->get_lookup (i));