Messages in this thread Patch in this message | | | From | David Daney <> | Subject | [PATCH] trace-cmd: Don't try to read unmapped memory. | Date | Wed, 14 Jul 2010 15:12:10 -0700 |
| |
When tracecmd_peek_data() reads the last event by calling translate_data(), it will get type_len = 0, length = -4. It had to read 8 bytes of data, but it adjusts the index by -4, for a net increment of 4. The invariant that the index points to an entire event ceases to hold.
If the index were already at the last event in the mapped area, a subsequent tracecmd_peek_data() checks that the index is not beyond the end of the mapping (which it isn't), but it assumes that the entire event will fit (which it doesn't). It then attempts to read an entire event (8 bytes), but the last 4 bytes are now beyond the end of the mapping causing a fault.
My fix is to keep the index pointing at the last record when the negative length is encountered.
On my x86_64 workstation, the mappings of the trace data were always contiguous with other mapped memory, so the reading of 4 bytes past the end of the mapping always fell on another piece of mapped memory, so no fault was produced. Running under valgrind or on a MIPS64 host was necessary to produce the fault.
Signed-off-by: David Daney <ddaney@caviumnetworks.com> --- trace-input.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/trace-input.c b/trace-input.c index 398d0f9..2ba346d 100644 --- a/trace-input.c +++ b/trace-input.c @@ -1530,6 +1530,18 @@ read_again: type_len = translate_data(handle, &ptr, &extend, &length); + if (length < 0) { + /* + * Negative length indicates the end. Back up ptr so + * subsequent reads don't fall off the end of the + * mapping. + */ + ptr -= 8; + handle->cpu_data[cpu].index = calc_index(handle, ptr, cpu); + handle->cpu_data[cpu].next = NULL; + return NULL; + } + switch (type_len) { case RINGBUF_TYPE_PADDING: if (!extend) { -- 1.6.6.1
| |