Bugzilla – Bug 1131362
VUL-0: CVE-2018-12183: ovmf,OVMF: edk2: stack overflow in DxeCore leads to privilege escalation
Last modified: 2019-04-11 07:00:04 UTC
Stack overflow in DxeCore for EDK II may allow an unauthenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.
The patch enables stack guard in CpuMpPei and it actually needs to pull in more stack guard patches. On the other hand, the CVE is about DxeCore and I'm still trying to figure out why the patch in CpuMpPei could fix the bug...
I did a quick search for the backporting of Stack Guard, and we need at least 26 patches to enable Stack Guard in SLE15 OVMF. I'm hesitant to merge them into SLE15 since those patches change the CPU and virtual memory drivers. Besides, Stack Guard requires the guest to enable NX in CPU, and the user has to configure qemu settings to enable the feature. What worries me more is that Stack Guard is currently not enabled by default due to the hardware dependency, so the feature is not really tested even in Tumbleweed.
On the other hand, the root cause is that ProcessSection() in MdeModulePkg/Core/Pei/FwVol/FwVol.c calls itself unlimitedly due to the crafted FV image, and upstream wants to use Stack Guard to detect the stack overflow and avoid code execution in the stack. I feel the "fix" is overkill. A better fix would be to refactor ProcessSection() non-recursively or just limit the number of recursions.
i am fine with skipping this issue after your explanation.
As Laszlo, the upstream OVMF maintainer, explained in upstream bug(*), OVMF doesn't provide the means to update FV images, so OVMF is actually not vulnerable to this issue.