Versions of the v86d userspace helper for the Linux uvesafb driver before 0.1.10 did not verify that received netlink messages were sent by the kernel, allowing unprivileged users to manipulate the video mode and potentially other consequences. v86d executes video BIOS code with access to /dev/mem in response to netlink messages, using either vm86 mode or an x86 emulator, depending on configuration. I an unclear on whether it is possible to e.g. crash the machine or escalate privileges by spoofing requests, or only to mess with the video card. References: http://repo.or.cz/w/v86d.git/commit/f9abfd412639286c3143e93e8ba2c9598dfba640 Is it OK to stabilize =sys-apps/v86d-0.1.10?
Michał, could you also provide more info about possible impact? For now I'm rating it B1, because we can't rule out local privilege escalation.
It should be OK to stabilize the new version in an expedited manner. The only difference between 0.1.10 and 0.1.9 is the sender verification. 0.1.10 also includes a patch, which has however been also included in 0.1.9 in Gentoo. The primary impact is that any user is able to change the video mode, which would lead to display corruption, as neither the kernel nor X would be informed about the video mode being changed. Other than that, it also makes it possible for any user to execute int 0x10 (video BIOS services). I'm not sure if there is any way to exploit this for privilege escalation.
Thank you. Arches, please stabilize =sys-apps/v86d-0.1.10
amd64 ok few problem with depend, posted on bug 356689
amd64 done. Thanks Agostino
x86 stable, last one so update the whiteboard
Thanks, everyone. GLSA Vote: no.
CVE assignment per http://www.openwall.com/lists/oss-security/2011/02/28/10.
Vote: NO. Closing noglsa.
