A flaw was found in the implementation of the Linux kernels GSS mechanism registration functionality. A memory allocation during this period would not be freed when the module was unloaded. A local attacker with the ability to unload and reload the "rpcsec_gss_krb5" kernel module (a privileged operation) is able to leak kernel memory that is unable to be reclaimed. Over time this can cause a denial of service, crashing the system or possibly having other unknown side effects. A non root (or CAP_SYS_ADMIN) user is unable to trigger this flaw as loading and unloading of kernel modules requires advanced permissions.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1832862]
Upstream Issue: https://bugzilla.kernel.org/show_bug.cgi?id=206651
Mitigation: There is no mitigation to this flaw other than to prevent the loading of the affected kernel module. A user with permission to load a kernel module would also likely have permission to overcome any blacklisting on the system.
I'm having trouble reaching cve.mitre.org, but this sounds like the same flaw addressed by these patches posted today by Neil Brown: https://lore.kernel.org/r/159003086409.24897.4659128962844846611.stgit@noble I agree that the memory leak sounds like a mild issue. However, he also points out: "The rpcsec_gss_krb5 module registers 2 flavours but does not unregister them, so if you load, unload, reload the module, it will happily continue to use the old registration which now has pointers to the memory were the module was originally loaded." I'm trying to sort out whether that's an issue.
Looks like after unloading and reloading the rpcsec_gss_krb5 module, we can end up with an auth_domain in the auth_domain table with ->name still an address from the previous module (one of the strings assigned to .name fields in gss_kerberos_pfs[].) So in auth_domain_lookup() and auth_domain_find(), the accesses of hp->name in strcmp(hp->name, name) will be reading from those old addresses. I think that's all. That still doesn't sound too serious to me--am I missing anything?
Statement: This issue is rated as having Low impact because of the preconditions needed to trigger the issue (privileges requried to mount/unmount a module). The issue is also being disputed with MITRE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12656) as being a non-issue because of the privileges required.
This was fixed for Fedora with the 5.7.13 stable kernel updates.