Full Report
Virtualization, especially with hypervisors in place, needs to ensure that no assets leak from one virtual machine to the other or from the hypervisor to the virtual machine. Failure to do so may result in vm escapes or cross-box contamination. In the mainline Linux kernel for 5.18-rc1 to 5.19-rc6, statically allocated .bss (block starting symbol) were not being cleared upon moving between XenPV guests and hosts. Because of this, a virtual machine guest connecting to the Xen IOMMU could access restricted memory. This can be done by calling kexec() from the guest. This appears to be a regression issue while attempting to add support for the hypervisor. The proof of concept has a simply NULL pointer dereference but could be much worse. Overall, an interesting and impactful bug. But, I wish the explaination in the article was easier to understand. The proof of concept is just a crash log and doesn't say how this was triggered.
Analysis Summary
# Vulnerability: Linux Kernel XenPV .bss Memory Clearing Failure
## CVE Details
- CVE ID: CVE-2022-36123
- CVSS Score: N/A (Severity not explicitly provided in the summary, though impact suggests High)
- CWE: Not explicitly available
## Affected Systems
- Products: Linux Kernel Mainline
- Versions: v5.18-rc1 through v5.19-rc6
- Configurations: Affects XenPV guests connecting to the Xen IOMMU, especially when the `CONFIG_XEN_VIRTIO` kernel configuration is in use.
## Vulnerability Description
This vulnerability is a regression introduced during efforts to add hypervisor support, specifically affecting XenPV guests. The flaw lies in the failure to properly clear statically allocated variables in the `.bss` (Block Starting Symbol) section of memory upon certain operations when moving between a XenPV guest and the host. If the `early_xen_iret_patch` fails, or if `kexec()` is called from the guest, the subsequent kernel (or state) may use uninitialized values in the `.bss` segment inherited from the previous execution context (the guest or hypervisor interaction). This memory leak allows a guest to potentially access restricted memory spaces managed by the Xen IOMMU via features like `xen_set_restricted_virtio_memory_access`.
## Exploitation
- Status: PoC available (The description mentions a PoC resulting in a NULL Pointer Dereference/crash).
- Complexity: Low to Medium (Requires local access within a XenPV guest environment).
- Attack Vector: Local (Requires execution within a vulnerable guest VM).
## Impact
- Confidentiality: Potential (Access to restricted memory could lead to information disclosure).
- Integrity: High (Arbitrary code execution or kernel state corruption is possible).
- Availability: High (Can lead to kernel oops, Denial of Service, or system crash).
## Remediation
### Patches
- **Linux Kernel Mainline Fix (Commit Hashes):**
- `36e2f161fb01795722f2ff1a24d95f08100333dd` (Fixes the regression by ensuring `.brk` is cleared at early boot).
- `38fa5479b41376dc9d7f57e71c83514285a25ca0` (Upstream fix description).
- **Stable Releases:** Fixed in Linux kernel stable version **5.18.13** and later.
### Workarounds
- Ensure the host hypervisor and guest kernel are updated past the affected range.
- If unable to patch immediately, restricting `kexec()` functionality from untrusted guests or limiting guest access to IOMMU/restricted memory functions might reduce the exploitability of gaining full code execution rights, though this does not fix the underlying memory clearing issue.
## Detection
- **Indicators of Compromise:** Unexpected kernel panics/crashes (asm\_exc\_page\_fault or kernel oops) originating from a XenPV guest environment, particularly during memory access operations involving IOMMU setup or `kexec`.
- **Detection Methods and Tools:** Monitoring system logs for abnormal kernel crashes, or using kernel debugging tools to inspect `.bss` memory contents across context switches in Xen environments.
## References
- Vendor Advisory (Implied by Stable Release Info): Kernel.org changelogs for 5.18.13.
- Relevant Links:
- Reference Link (Sick Codes Article): hxxps://sick.codes/sick-2022-128/