Description of problem: The PVFB backend is a user space program running as root in dom0. A buggy or malicious frontend can describe its shared framebuffer to it in a way that makes it map an arbitrary amount of guest memory, malloc an arbitrarily large internal buffer, or copy arbitrary memory to that buffer. A domU running a malicious frontend can abuse the former two for a denial of service attack against dom0. It can abuse all three to terminate or crash the backend. If there's anything in the backend's address space that gets tickled the wrong way by being read, the last one is more serious, but I'm not aware of anything like that. Version-Release number of selected component (if applicable): I believe all versions are vulnerable to the first two abuses, and all versions since 3.0.3-45.el5 are additionally vulnerable to the third one. How reproducible: Haven't tried, should be 100%. Steps to Reproduce: I can prepare a malicious frontend if necessary.
Created attachment 302934 [details] Proposed fix The fix makes the backend validate the framebuffer description presented by the frontend on its shared page on initialization. Code executing after initialization is not touched. All frontends we've shipped so far present the same, fixed set of parameters, which validates fine.
This issue is enhanced by the CVE-2008-1952 (another size limit check added).
Public paper about exploitation of this flaw: http://marc.info/?l=dailydave&m=122407972124773&w=2 http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf
This was addressed via: Red Hat Enterprise Linux version 5 (RHSA-2008:0194) RHEL Virtualization version 5 (RHSA-2008:0194)