| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2021-47369: s390/qeth: fix NULL deref in qeth_clear_working_pool_list() |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| s390/qeth: fix NULL deref in qeth_clear_working_pool_list() |
| |
| When qeth_set_online() calls qeth_clear_working_pool_list() to roll |
| back after an error exit from qeth_hardsetup_card(), we are at risk of |
| accessing card->qdio.in_q before it was allocated by |
| qeth_alloc_qdio_queues() via qeth_mpc_initialize(). |
| |
| qeth_clear_working_pool_list() then dereferences NULL, and by writing to |
| queue->bufs[i].pool_entry scribbles all over the CPU's lowcore. |
| Resulting in a crash when those lowcore areas are used next (eg. on |
| the next machine-check interrupt). |
| |
| Such a scenario would typically happen when the device is first set |
| online and its queues aren't allocated yet. An early IO error or certain |
| misconfigs (eg. mismatched transport mode, bad portno) then cause us to |
| error out from qeth_hardsetup_card() with card->qdio.in_q still being |
| NULL. |
| |
| Fix it by checking the pointer for NULL before accessing it. |
| |
| Note that we also have (rare) paths inside qeth_mpc_initialize() where |
| a configuration change can cause us to free the existing queues, |
| expecting that subsequent code will allocate them again. If we then |
| error out before that re-allocation happens, the same bug occurs. |
| |
| Root-caused-by: Heiko Carstens <hca@linux.ibm.com> |
| |
| The Linux kernel CVE team has assigned CVE-2021-47369 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.9 with commit eff73e16ee116f6eafa2be48fab42659a27cb453 and fixed in 5.10.70 with commit db94f89e1dadf693c15c2d60de0c34777cea5779 |
| Issue introduced in 5.9 with commit eff73e16ee116f6eafa2be48fab42659a27cb453 and fixed in 5.14.9 with commit 9b00fb12cdc9d8d1c3ffe82a78e74738127803fc |
| Issue introduced in 5.9 with commit eff73e16ee116f6eafa2be48fab42659a27cb453 and fixed in 5.15 with commit 248f064af222a1f97ee02c84a98013dfbccad386 |
| Issue introduced in 5.7.16 with commit b2400fe7e1011c5f3dc2268e8382082465b1c8a2 |
| Issue introduced in 5.8.2 with commit 22697ca855c06a4a1264d5651542b7d98870a8c4 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2021-47369 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/s390/net/qeth_core_main.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/db94f89e1dadf693c15c2d60de0c34777cea5779 |
| https://git.kernel.org/stable/c/9b00fb12cdc9d8d1c3ffe82a78e74738127803fc |
| https://git.kernel.org/stable/c/248f064af222a1f97ee02c84a98013dfbccad386 |
