On 29/08/2024 4:53 pm, Roger Pau Monné wrote: > On Fri, Aug 23, 2024 at 06:05:03PM +0100, Javi Merino wrote: >> When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)" >> call in main_dmesg(). ASAN reports a heap buffer overflow: an >> off-by-one access to cr->buffer. >> >> The readconsole sysctl copies up to count characters into the buffer, >> but it does not add a null character at the end. Despite the >> documentation of libxl_xen_console_read_line(), line_r is not >> nul-terminated if 16384 characters were copied to the buffer. >> >> Fix this by asking xc_readconsolering() to fill the buffer up to size >> - 1. As the number of characters in the buffer is only needed in >> libxl_xen_console_read_line(), make it a local variable there instead >> of part of the libxl__xen_console_reader struct. > Instead of playing games with the buffer size in order to add an extra > NUL character, we could possibly use libxl_write_exactly(ctx, > STDOUT_FILENO,...) in main_dmesg(), using cr->count as the buffer > length?
Sadly no. struct libxl__xen_console_reader (which has the count field) is a libxl private (opaque) type which `xl` can't access. Otherwise this would be a oneline fix already... ~Andrew