В ядре Linux устранена следующая уязвимость:
soc: fsl: qbman: исправить состояние гонки в qman_destroy_fq
Когда установлен QMAN_FQ_FLAG_DYNAMIC_FQID, возникает состояние гонки между
состояние fq_table[fq->idx] и освобождение/выделение из пула и
WARN_ON(fq_table[fq->idx]) в qman_create_fq() срабатывает.
Действительно, мы можем иметь:
Резьба А Резьба Б
qman_destroy_fq() qman_create_fq()
qman_release_fqid()
qman_shutdown_fq()
gen_pool_free()
-- На этом этапе fqid снова доступен --
qman_alloc_fqid()
-- итак, мы можем получить только что освобожденный fqid в потоке B --
fq->fqid = fqid;
fq->idx = fqid * 2;
WARN_ON(fq_table[fq->idx]);
fq_table[fq->idx] = fq;
fq_table[fq->idx] = NULL;
И добавление некоторых журналов между qman_release_fqid() и
fq_table[fq->idx] = NULL делает триггер WARN_ON() намного более активным.
Чтобы предотвратить это, убедитесь, что для fq_table[fq->idx] установлено значение NULL перед
gen_pool_free() вызывается с помощью smp_wmb().
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: fix race condition in qman_destroy_fq When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between fq_table[fq->idx] state and freeing/allocating from the pool and WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered. Indeed, we can have: Thread A Thread B qman_destroy_fq() qman_create_fq() qman_release_fqid() qman_shutdown_fq() gen_pool_free() -- At this point, the fqid is available again -- qman_alloc_fqid() -- so, we can get the just-freed fqid in thread B -- fq->fqid = fqid; fq->idx = fqid * 2; WARN_ON(fq_table[fq->idx]); fq_table[fq->idx] = fq; fq_table[fq->idx] = NULL; And adding some logs between qman_release_fqid() and fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more. To prevent that, ensure that fq_table[fq->idx] is set to NULL before gen_pool_free() is called by using smp_wmb().