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/allo…

Overview

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().

Affected

• linux_kernel >= 4.9, < 5.10.253
• linux_kernel >= 5.11, < 5.15.203
• linux_kernel >= 5.16, < 6.1.167
• linux_kernel >= 6.2, < 6.6.130
• linux_kernel >= 6.7, < 6.12.78
• linux_kernel >= 6.13, < 6.18.20
• linux_kernel >= 6.19, < 6.19.10
• linux_kernel = 7.0

Remediation

Upgrade past the affected range:

• linux_kernel 6.19.10