linux-kernel - Re: [PATCH v2] drm/vmwgfx: Work around VMW_ALLOC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 Feb 2023 10:46:51 +0800
From:   Meng Tang <tangmeng@...ontech.com>
To:     Zack Rusin <zackr@...are.com>, "daniel@...ll.ch" <daniel@...ll.ch>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Linux-graphics-maintainer <Linux-graphics-maintainer@...are.com>,
        "airlied@...il.com" <airlied@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drm/vmwgfx: Work around VMW_ALLOC_DMABUF

On 2023/2/23 20:50, Zack Rusin wrote:
> On Thu, 2023-02-23 at 15:04 +0800, Meng Tang wrote:
>> A privilege escalation vulnerability was found in vmwgfx driver
>> in drivers/gpu/drm/vmwgfx/vmwgfx_drv.c in GPU component of Linux
>> kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw
>> allows a local attacker with a user account on the system to gain
>> privilege, causing a denial of service(DoS).
>>
>> This vulnerability can be quickly verified by the following code
>> logic:
>> ...
>> dri_fd = open("/dev/dri/renderD128", O_RDWR);
>> ret = ioctl(dri_fd, 0xC0186441, &arg);
>> if (ret == 0) {
>>          printf("[*] VMW_ALLOC_DMABUF Success!\n");
>> }
>> ...
> 
> This is just regular usage of that ioctl. What's the vulnerability?
> 
Yes, this is a very common regular usage of that ioctl.
But if any user can operate /dev/dri/renderD128 through ioctl, it will 
lead to a vulnerability.
>>
>> Submit this commit to fix it.
> 
> No, this is incorrect. You're effectively just disabling the driver for normal
> apps/users using OpenGL or any accelerated contexts, which is going to completely
> break, well, essentially everything this driver is for. Being able to use ioctl's
> that were meant to be used is not a bug.
> 
> If you have a proof of concept or at least a description of the vulnerability that
> you've found I'd be happy to take a look at it.
> 
> z


$ ls /dev/dri/renderD128 -la
crw-rw----+ 1 root render 226, 128 2?  15 11:45 /dev/dri/renderD128

The permission of the file is ”crw-rw----+”.
I think only the root user or users with certain privileges can access 
the /dev/dri/renderD128 device file at this time.

But in fact, users can access /dev/dri/renderD128 through ioctl without 
permission.

Attachment poc.c is a test case, any user can execute the 
case(VMW_ALLOC_DMABUF) successfully, and eventually lead to a call 
trace(log see attachment dmesg.txt).

This will cause the user with permission VMW_ALLOC_DMABUF failed.

Therefore, I think that according to the permissions shown by 
“crw-rw----+ 1 root render”, only the root user or users with certain 
privileges can VMW_ALLOC_DMABUF success.
View attachment "poc.c" of type "text/x-csrc" (1000 bytes)

View attachment "dmesg.txt" of type "text/plain" (2950 bytes)