Bugzilla – Bug 1213195
VUL-0: CVE-2023-3108: kernel-source-azure,kernel-source,kernel-source-rt: race condition in crypto module in the function skcipher_recvmsg
Last modified: 2023-07-13 09:17:26 UTC
CVE-2023-3108 A flaw in the Linux Kernel interface for symmetric key cipher algorithms found (in the function skcipher_recvmsg of crypto/algif_skcipher.c). When the function skcipher_recvmsg receives data from the socket to obtain the encryption and decryption results, it can go to skcipher_wait_for_data to wait for the data in the socket to arrive, but the value passed to af_alg_make_sg after the data arrives is still 0, which will cause a crash in the subsequent get_user_pages_fast. After analyses of the reproducer, there is a conclusion that this issue is only locally exploitable. Upstream fix: https://github.com/torvalds/linux/commit/9399f0c51489ae8c16d6559b82a452fdc1895e91 Commit introducing the bug: https://github.com/torvalds/linux/commit/1d10eb2f156f5fc83cf6c7ce60441592e66eadb3 Reference: https://github.com/torvalds/linux/commit/9399f0c51489ae8c16d6559b82a452fdc1895e91 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3108 https://bugzilla.redhat.com/show_bug.cgi?id=2221472
Both fixing and buggy commits were introduced in v4.0-rc1. I don't really know why a CVE is assigned now. Since both commits were introduced in the same version, our branches containing the buggy commit also have the fixing one. Leaving open to add the CVE id in the changelogs: - SLE15-SP4 - cve/linux-4.12 - cve/linux-4.4 - cve/linux-5.3 - stable
(In reply to Thomas Leroy from comment #1) > Both fixing and buggy commits were introduced in v4.0-rc1. I don't really > know why a CVE is assigned now. > > Since both commits were introduced in the same version, our branches > containing the buggy commit also have the fixing one. Leaving open to add > the CVE id in the changelogs: > > - SLE15-SP4 > - cve/linux-4.12 > - cve/linux-4.4 > - cve/linux-5.3 > - stable Looks like we don't need to backport this patch since it has been included in the upstream kernel bases we selected, which means no kernel patch metadata needs to be revised for this CVE. Not sure if anything the kernel team can help with so reassign this CVE back to the security team, thanks.