| 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-47131: net/tls: Fix use-after-free after the TLS device goes down and up |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| net/tls: Fix use-after-free after the TLS device goes down and up |
| |
| When a netdev with active TLS offload goes down, tls_device_down is |
| called to stop the offload and tear down the TLS context. However, the |
| socket stays alive, and it still points to the TLS context, which is now |
| deallocated. If a netdev goes up, while the connection is still active, |
| and the data flow resumes after a number of TCP retransmissions, it will |
| lead to a use-after-free of the TLS context. |
| |
| This commit addresses this bug by keeping the context alive until its |
| normal destruction, and implements the necessary fallbacks, so that the |
| connection can resume in software (non-offloaded) kTLS mode. |
| |
| On the TX side tls_sw_fallback is used to encrypt all packets. The RX |
| side already has all the necessary fallbacks, because receiving |
| non-decrypted packets is supported. The thing needed on the RX side is |
| to block resync requests, which are normally produced after receiving |
| non-decrypted packets. |
| |
| The necessary synchronization is implemented for a graceful teardown: |
| first the fallbacks are deployed, then the driver resources are released |
| (it used to be possible to have a tls_dev_resync after tls_dev_del). |
| |
| A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback |
| mode. It's used to skip the RX resync logic completely, as it becomes |
| useless, and some objects may be released (for example, resync_async, |
| which is allocated and freed by the driver). |
| |
| The Linux kernel CVE team has assigned CVE-2021-47131 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 4.18 with commit e8f69799810c32dd40c6724d829eccc70baad07f and fixed in 5.10.43 with commit f1d4184f128dede82a59a841658ed40d4e6d3aa2 |
| Issue introduced in 4.18 with commit e8f69799810c32dd40c6724d829eccc70baad07f and fixed in 5.12.10 with commit 0f1e6fe66977a864fe850522316f713d7b926fd9 |
| Issue introduced in 4.18 with commit e8f69799810c32dd40c6724d829eccc70baad07f and fixed in 5.13 with commit c55dcdd435aa6c6ad6ccac0a4c636d010ee367a4 |
| |
| 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-47131 |
| 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: |
| include/net/tls.h |
| net/tls/tls_device.c |
| net/tls/tls_device_fallback.c |
| net/tls/tls_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/f1d4184f128dede82a59a841658ed40d4e6d3aa2 |
| https://git.kernel.org/stable/c/0f1e6fe66977a864fe850522316f713d7b926fd9 |
| https://git.kernel.org/stable/c/c55dcdd435aa6c6ad6ccac0a4c636d010ee367a4 |
