Improper Input Validation Affecting kernel-doc package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsSnyk Learn
Learn about Improper Input Validation vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-RHEL8-KERNELDOC-6336266
- published29 Feb 2024
- disclosed28 Feb 2024
Introduced: 28 Feb 2024
CVE-2021-46978 (opens in a new tab)How to fix?
There is no fixed version for RHEL:8 kernel-doc.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-doc package and not the kernel-doc package as distributed by RHEL.
See How to fix? for RHEL:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Always make an attempt to map eVMCS after migration
When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request.
Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.
As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state().
References
- https://access.redhat.com/security/cve/CVE-2021-46978
- https://git.kernel.org/stable/c/200a45649ab7361bc80c70aebf7165b64f9a6c9f
- https://git.kernel.org/stable/c/bd0e8455b85b651a4c77de9616e307129b15aaa7
- https://git.kernel.org/stable/c/c8bf64e3fb77cc19bad146fbe26651985b117194
- https://git.kernel.org/stable/c/f5c7e8425f18fdb9bdb7d13340651d7876890329