qemu/hw/display/ramfb.c
Laszlo Ersek 7771e35b39 hw/display/ramfb: plug slight guest-triggerable leak on mode setting
The fw_cfg DMA write callback in ramfb prepares a new display surface in
QEMU; this new surface is put to use ("swapped in") upon the next display
update. At that time, the old surface (if any) is released.

If the guest triggers the fw_cfg DMA write callback at least twice between
two adjacent display updates, then the second callback (and further such
callbacks) will leak the previously prepared (but not yet swapped in)
display surface.

The issue can be shown by:

(1) starting QEMU with "-trace displaysurface_free", and

(2) running the following program in the guest UEFI shell:

> #include <Library/ShellCEntryLib.h>           // ShellAppMain()
> #include <Library/UefiBootServicesTableLib.h> // gBS
> #include <Protocol/GraphicsOutput.h>          // EFI_GRAPHICS_OUTPUT_PROTOCOL
>
> INTN
> EFIAPI
> ShellAppMain (
>   IN UINTN   Argc,
>   IN CHAR16  **Argv
>   )
> {
>   EFI_STATUS                    Status;
>   VOID                          *Interface;
>   EFI_GRAPHICS_OUTPUT_PROTOCOL  *Gop;
>   UINT32                        Mode;
>
>   Status = gBS->LocateProtocol (
>                   &gEfiGraphicsOutputProtocolGuid,
>                   NULL,
>                   &Interface
>                   );
>   if (EFI_ERROR (Status)) {
>     return 1;
>   }
>
>   Gop = Interface;
>
>   Mode = 1;
>   for ( ; ;) {
>     Status = Gop->SetMode (Gop, Mode);
>     if (EFI_ERROR (Status)) {
>       break;
>     }
>
>     Mode = 1 - Mode;
>   }
>
>   return 1;
> }

The symptom is then that:

- only one trace message appears periodically,

- the time between adjacent messages keeps increasing -- implying that
  some list structure (containing the leaked resources) keeps growing,

- the "surface" pointer is ever different.

> 18566@1695127471.449586:displaysurface_free surface=0x7f2fcc09a7c0
> 18566@1695127471.529559:displaysurface_free surface=0x7f2fcc9dac10
> 18566@1695127471.659812:displaysurface_free surface=0x7f2fcc441dd0
> 18566@1695127471.839669:displaysurface_free surface=0x7f2fcc0363d0
> 18566@1695127472.069674:displaysurface_free surface=0x7f2fcc413a80
> 18566@1695127472.349580:displaysurface_free surface=0x7f2fcc09cd00
> 18566@1695127472.679783:displaysurface_free surface=0x7f2fcc1395f0
> 18566@1695127473.059848:displaysurface_free surface=0x7f2fcc1cae50
> 18566@1695127473.489724:displaysurface_free surface=0x7f2fcc42fc50
> 18566@1695127473.969791:displaysurface_free surface=0x7f2fcc45dcc0
> 18566@1695127474.499708:displaysurface_free surface=0x7f2fcc70b9d0
> 18566@1695127475.079769:displaysurface_free surface=0x7f2fcc82acc0
> 18566@1695127475.709941:displaysurface_free surface=0x7f2fcc369c00
> 18566@1695127476.389619:displaysurface_free surface=0x7f2fcc32b910
> 18566@1695127477.119772:displaysurface_free surface=0x7f2fcc0d5a20
> 18566@1695127477.899517:displaysurface_free surface=0x7f2fcc086c40
> 18566@1695127478.729962:displaysurface_free surface=0x7f2fccc72020
> 18566@1695127479.609839:displaysurface_free surface=0x7f2fcc185160
> 18566@1695127480.539688:displaysurface_free surface=0x7f2fcc23a7e0
> 18566@1695127481.519759:displaysurface_free surface=0x7f2fcc3ec870
> 18566@1695127482.549930:displaysurface_free surface=0x7f2fcc634960
> 18566@1695127483.629661:displaysurface_free surface=0x7f2fcc26b140
> 18566@1695127484.759987:displaysurface_free surface=0x7f2fcc321700
> 18566@1695127485.940289:displaysurface_free surface=0x7f2fccaad100

We figured this wasn't a CVE-worthy problem, as only small amounts of
memory were leaked (the framebuffer itself is mapped from guest RAM, QEMU
only allocates administrative structures), plus libvirt restricts QEMU
memory footprint anyway, thus the guest can only DoS itself.

Plug the leak, by releasing the last prepared (not yet swapped in) display
surface, if any, in the fw_cfg DMA write callback.

Regarding the "reproducer", with the fix in place, the log is flooded with
trace messages (one per fw_cfg write), *and* the trace message alternates
between just two "surface" pointer values (i.e., nothing is leaked, the
allocator flip-flops between two objects in effect).

This issue appears to date back to the introducion of ramfb (995b30179b,
"hw/display: add ramfb, a simple boot framebuffer living in guest ram",
2018-06-18).

Cc: Gerd Hoffmann <kraxel@redhat.com> (maintainer:ramfb)
Cc: qemu-stable@nongnu.org
Fixes: 995b30179b
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20230919131955.27223-1-lersek@redhat.com>
(cherry picked from commit e0288a778473ebd35eac6cc1924faca7d477d241)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-05 08:44:22 +03:00

137 lines
3.5 KiB
C

/*
* early boot framebuffer in guest ram
* configured using fw_cfg
*
* Copyright Red Hat, Inc. 2017
*
* Author:
* Gerd Hoffmann <kraxel@redhat.com>
*
* This work is licensed under the terms of the GNU GPL, version 2 or later.
* See the COPYING file in the top-level directory.
*/
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "hw/loader.h"
#include "hw/display/ramfb.h"
#include "hw/display/bochs-vbe.h" /* for limits */
#include "ui/console.h"
#include "sysemu/reset.h"
struct QEMU_PACKED RAMFBCfg {
uint64_t addr;
uint32_t fourcc;
uint32_t flags;
uint32_t width;
uint32_t height;
uint32_t stride;
};
struct RAMFBState {
DisplaySurface *ds;
uint32_t width, height;
struct RAMFBCfg cfg;
};
static void ramfb_unmap_display_surface(pixman_image_t *image, void *unused)
{
void *data = pixman_image_get_data(image);
uint32_t size = pixman_image_get_stride(image) *
pixman_image_get_height(image);
cpu_physical_memory_unmap(data, size, 0, 0);
}
static DisplaySurface *ramfb_create_display_surface(int width, int height,
pixman_format_code_t format,
hwaddr stride, hwaddr addr)
{
DisplaySurface *surface;
hwaddr size, mapsize, linesize;
void *data;
if (width < 16 || width > VBE_DISPI_MAX_XRES ||
height < 16 || height > VBE_DISPI_MAX_YRES ||
format == 0 /* unknown format */)
return NULL;
linesize = width * PIXMAN_FORMAT_BPP(format) / 8;
if (stride == 0) {
stride = linesize;
}
mapsize = size = stride * (height - 1) + linesize;
data = cpu_physical_memory_map(addr, &mapsize, false);
if (size != mapsize) {
cpu_physical_memory_unmap(data, mapsize, 0, 0);
return NULL;
}
surface = qemu_create_displaysurface_from(width, height,
format, stride, data);
pixman_image_set_destroy_function(surface->image,
ramfb_unmap_display_surface, NULL);
return surface;
}
static void ramfb_fw_cfg_write(void *dev, off_t offset, size_t len)
{
RAMFBState *s = dev;
DisplaySurface *surface;
uint32_t fourcc, format, width, height;
hwaddr stride, addr;
width = be32_to_cpu(s->cfg.width);
height = be32_to_cpu(s->cfg.height);
stride = be32_to_cpu(s->cfg.stride);
fourcc = be32_to_cpu(s->cfg.fourcc);
addr = be64_to_cpu(s->cfg.addr);
format = qemu_drm_format_to_pixman(fourcc);
surface = ramfb_create_display_surface(width, height,
format, stride, addr);
if (!surface) {
return;
}
s->width = width;
s->height = height;
qemu_free_displaysurface(s->ds);
s->ds = surface;
}
void ramfb_display_update(QemuConsole *con, RAMFBState *s)
{
if (!s->width || !s->height) {
return;
}
if (s->ds) {
dpy_gfx_replace_surface(con, s->ds);
s->ds = NULL;
}
/* simple full screen update */
dpy_gfx_update_full(con);
}
RAMFBState *ramfb_setup(Error **errp)
{
FWCfgState *fw_cfg = fw_cfg_find();
RAMFBState *s;
if (!fw_cfg || !fw_cfg->dma_enabled) {
error_setg(errp, "ramfb device requires fw_cfg with DMA");
return NULL;
}
s = g_new0(RAMFBState, 1);
rom_add_vga("vgabios-ramfb.bin");
fw_cfg_add_file_callback(fw_cfg, "etc/ramfb",
NULL, ramfb_fw_cfg_write, s,
&s->cfg, sizeof(s->cfg), false);
return s;
}