From a5f6f869e80c371665026dfe9d156f0088f2553d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominik=20R=C3=B6ttsches?= Date: Fri, 23 Oct 2020 14:25:05 +0300 Subject: [PATCH] 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 --- src/hb-ot-layout-gsubgpos.hh | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/hb-ot-layout-gsubgpos.hh b/src/hb-ot-layout-gsubgpos.hh index cb62b0251..9ea27588d 100644 --- a/src/hb-ot-layout-gsubgpos.hh +++ b/src/hb-ot-layout-gsubgpos.hh @@ -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)); if (unlikely (!this->accels)) + { 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++) this->accels[i].init (table->get_lookup (i));