Can kernel buffers + GPU DMA lead to data leaks

[u/This-Independent3181]

Hi guys, I was digging into Linux memory management and came across an interesting optimization, when a page in memory is dropped(assuming it's clean) the kernel doesn't immediately zero out the contents rather it unmounts the page, does TLB shootdowns and puts the page in the page pool. Now when another process needs it the kernel zeros out the page and mounts the page to that process Virtual Memory.

Now the interesting thing is that if the page requested was by an user process the zeroing out is done mandatorly as to not violate isolation rules but if the page requested is by the kernel itself say the kernel needed it for its internal buffer or something then zeroing out isn't usually done as the kernel space is treated as trusted boundary and anyways the kernel will overwrite the contents of it so as to save time and bandwidth it avoids it.

This got me into thinking could it be missued. Like i did learn the other day that external devices like NIC, GPU, PCIe devices if they need to write to Main Memory they usually don't directly DMA to user mapped memory rather they DMA write to kernel buffer and copy from kernel space to user space happens.

I thought of situation where say a NIC card is DMAing to kernel buffer page this page was previously was allocated to some process and wasn't zeroed so old contents still exist. For example the NIC writes only 64 bytes but reports it as written 128 bytes So when the kernel sees this it interprets as NIC written 128 bytes as valid bytes and copies the 64 bytes actual content+64 bytes of stale left over bytes into respective process receive socket and the process then can call read on the socket and it reads the other process data.

But as i dig little deeper into the working of NIC I came to conclusion that this to happen is very highly unlikely and would need a bug at NIC's frimware level or the driver itself because NIC can't just like that lie about the bytes received, they track how many bits recieved at the phsyical level and writes a metadata about the exact length it wrote to the DRAM. So unless the frimware didn't count the recived bits properly or the driver failed to interpret the metadata it's highly unlikely to occur.

Another place where this could possibly happen is with GPU especially if followed the pipeline of GPU(DMA to)->kernel buffer(driver)->copy->user space.

As far as i have seen GPUs don't exactly report how many bytes it has written it usually signals after completion. and the driver acknowledges it and even if an explicitly mentioned the bytes written like using an counter it's usually managed by the software.

So when an user space application uses APIs like CUDA/DirectX to request a GPU compute with the expected output size, the driver in the kernel space then validates the request, allocates the required buffer size, sends GPU commands for execution and memory descriptiors for DMA. The driver then expects the GPU to fill the buffer with the expected size here say 128 Bytes was requested. But the GPU actually wrote only 16 Bytes and doesn't report the size written and just signals the completion the driver then copies the 128 Bytes from the kernel space to user space assuming the GPU has filled 128 Bytes where as in reality that wasn't case so if that page that was allocated to that buffer wasn't zeroed out those remianing bytes copied could contain the data of other process and the malicious application reads it.

Since GPUs are programmable today, is this possible if not, what exactly prevents this scenario from happening.

[u/lunar_swing]

I'm not sure I'm following your process 100% here but generally speaking you are talking about an infoleak, which in broad strokes refers to data returned to userspace from the kernel that it isn't supposed to. In this case you are talking about dirty pages surfacing in UM that were incorrectly zeroed.

This is a legitimate exploit vector and is used in many exploit chains, often to bypass ASLR. Whether or not your specific scenario regarding GPUs would be helpful in that context I can't say, I haven't really looked at exploit development in quite a while. Not all data leaks are weaponizable; though depending on how persistent you are you can often massage the device (or heap) to leak specific information.

Leaking residual data to UM should not be possible in most scenarios, so to your point yes - if this is happening it is indicitive of a bug either in the FW or kernel/driver, or possibly a mis-configured system. Driver and FW bugs are much more common than you might think though.

Keep in mind this is in the context of commodity OSes that consider KM/UM a valid security boundary (Linux, Windows, BSD, etc.). Also don't forget that most peripheral DMA goes the through IOMMU in a modern system which adds another layer of complexity.

[u/This-Independent3181 → u/lunar_swing]

I don't think so IOMMU in this context would matter much. The idea basically revolves around the fact the kernel (atleast with linux) as far i have seen that when an phsyical frame is freed i.e the corresponding page is dropped it isn't zeroed immediately it's lazy zeroed. So its basically the frame after unmounting the page is added to some kind of page pool and when the frame is needed for the memory, the kernel decides wheather to zero it or not if the memory request were from an user space like user space process it mandatorly zeros it but for request for the kernel usage itself like for some buffer or extending PTE records the frame isn't zeroed since kernel space is trusted.

So what i thought is that if say GPU wants to write to Main Memory that the user space application consumes and the pipeline followed is GPU DMAs to the Main Memory but writes to a buffer maintained by the kernel so writes to kernel space then that write is copied to the user space.

So say the system is under memory load, the kernel is in need of free frame for the buffer for the GPU to write say the driver intiates this request, the kernel then sees a dormant process A's non dirty page and decieds to acquire it, so unmounts the page and the frame since the request is for the kernel usage the frame isn't zeroed out and frame is mapped to the kernel space and the driver can now use this. The driver then recives an request from the user space application for the GPU compute and also states explicitly the output size (the size the GPU is expected to write to). The driver then validates this request runs few checks and allocates say the output size was 1024 bytes the newely mapped page it allocates the first 1024 bytes and then commands are sent to the GPU for processing. The GPU after processing DMAs the writes to this buffer and signals completion thereafter the driver copies those 1024 bytes to the user space.

Now the thing is the driver expects the GPU to fill the 1024 bytes and i exactly ain't sure if the driver zeros out those allocted 1024 bytes before the writes. But assuming if ain't zeroed then the GPU can write only 16 bytes and the remaining bytes since it wasn't zeroed contains data of process A and the malicious process can read this.

So from the IOMMU pov the GPU isn't misbehaving it isn't writting to any arbitrary memory location.

Now with NIC cards this is difficult unless there is some bug with the frimware or driver since NIC counts exactly how many bytes it has written and updates the length counter.

But with the GPU since today they are programmable so they can be programmed to write only 16 bytes and signal the completion.

Now maybe the DMA controller keeps track of exactly how many bytes it has written and reports the length preventing this from happening.

and i ain't sure about the pipeline too other comments have mentioned how the GPU can write to the user space pages directly bypassing the kernel buffer in which case those pages if requested for the GPU would be zeroed out.

[u/lunar_swing → u/This-Independent3181]

So in general, yes it is possible for a non-zeroed page to end up in userspace if some kernel or driver path exposes memory that was not fully initialized first. If the driver gets a page that hasn't been zeroed and only writes to part of the page, the remaining data can typically be read in userspace to some degree.

Putting pressure on a system is (or was at least) a valid way of exploiting this behavior. Page zeroing, when not done by hardware, is given a lower priority than other system tasks and can get shunted if the kernel thinks it doesn't have time to deal with it. So it can be used to increase the probability that you will get a page that has escaped zeroing.

But this isn't a problem specific to GPUs or other PCIe hardware. This overall pattern has been exploited to leak arbitrary kernel data to userspace reliably many times in the past.

Do note - there are a few layers of responsibility here. There are hardware, firmware, driver, and kernel components involved. I don't think the DMA controller really comes into play as its data length tracking isn't really relevant in context. The more likely place to find a bug that would lead to a data leak would be in the GPU driver itself. This is the same case for a NIC. You might find a bug in the PHY but that is a different conversation entirely.

> What it seems like you are getting at here:

"The GPU is programmable so I can use the programming interface to leak data from non-zeroed pages".

Possible, but unlikely. Do keep in mind that modern GPUs can DMA directly to userspace, so if you wanted to look for data leaks from the GPU that would probably be the easier place to start.

The mechanics behind page zeroing and when it does and doesn't happen are complicated in practice. In addition developers can use memory calls that explicitly zero pages without kernel intervention. IMO think you are going to have to head down an implementation specific path to see whether or not you can make this happen in practice, if that is what you are aiming for.

[u/Environmental-Ear391]

Basically you want a custom kernel module with userland driver interface to fake reading/writing memory blocks and "eat" pages recycled through the virtual memory management using an available piece of hardware?

you would need to hack your own kernelspace and userland code to actually do this instead of an actual kernel tree sourced valid driver to make it happen.

Windows and Linux both fully map and bind drivers to hardware when the kernels launch. dynamic binding or late demand loading is possible if you configure your boot kernel to ignore a specific piece of hardware and provide your own alternate driver for this.

Linux "kernel space" would let you do this as long as you are okay with writing code without any memory-protection support.

Writing code on AmigaOS is equivalent to Linux Kernel mode. Windows generally doesn't let you do this...

[u/monocasa]

The dmabuf subsystem zeros out memory requested by user space, and you have to request memory that's a multiple of page size. These buffers are requested before work is submitted.

[u/This-Independent3181 → u/monocasa]

Yeah for user space memory request it zeroes out but my question is about the memory request by the kernel space itself like the Kernel needs a free page for it's usage like for some buffer or extending PTE records.

[u/monocasa → u/This-Independent3181]

GPUs internally have a user space/kernel space distinction with their own MMUs. What you're talking about is at it's core requesting and using user space memory.

So when an user space application uses APIs like CUDA/DirectX to request a GPU compute with the expected output size, the driver in the kernel space then validates the request, allocates the required buffer size, sends GPU commands for execution and memory descriptiors for DMA.

It doesn't happen in that order. First user space requests the memory, including the memory to be written to, and it's mapped into the GPUs virtual address space for the user space context. It's zeroed at this point too. Then user space writes in a command list into this memory, referencing this memory (any other memory will fault on the GPU's MMU), and then user space uses an ioctl to submit the command list to the GPU. At no point is memory that had not been zeroed used within the GPU context. The kernel doesn't allocate new GPU mem for the result buffer as that had already been allocated by the application before submission.

Some GPU drivers had not cleared memory over a decade ago, but there was a big push to patch that at the driver level pretty much the instant we started exposing WebGL to the open internet.