[Linux-fbdev-devel] 3 Security Problems

[Sottek, M. J <mat...@in...>]

I have discovered 3 security problems with the current framebuffers.
On some systems these may be serious issues with exploitable holes.

#1 The default mmap function allows any user with access to the
device to memory map whatever region is stored in mmio_base. On
chips with the ability to read arbitrary system memory this is a
hole that could easily allow root exploits. For systems with the
ability to write to arbitrary system memory this would be difficult
but possible to exploit. On almost all systems this could lead to
denial of service from locking the machine.
  In short, you cannot allow untrusted binaries to memory map mmio
regions for most graphics chips. Mapping of the MMIO regions has
to be limited to the root user.

#2 It seems most drivers are setting display->screen_base and
info->sysmem_size to reflect the entire available memory, not just
the framebuffer memory for the current mode. This could lead to
security problems for any driver that keeps command buffers or
double buffered registers in the framebuffer memory. Further it
is not possible at this time to set those values to indicate ONLY
the framebuffer because the fb X server incorrectly reads the
sysmem_size before setting the mode. For drivers that set
sysmem_size based on the actual framebuffer size X will get the
incorrect value.

#3 The current device read and write handlers do not account for
framebuffers with pitch != width. Reading from the device will
return all memory, even that outside the framebuffer.  This is
not an exploitable security hole but does raise the question as
to the correct behavior of read/write. I am ok with leaving it as
is, due to the fact that memory mapping the framebuffer would
give the same behavior. I do think that this has not been clearly
stated as the expected behavior.

-Matt