On Fri, 18 Nov 2016, Alexander Shishkin wrote: > From 139306c3bcf7abf49c51a8e56131aaae51222594 Mon Sep 17 00:00:00 2001 > From: Alexander Shishkin <[email protected]> > Date: Fri, 18 Nov 2016 13:24:55 +0200 > Subject: [PATCH] perf: Fix address filter parser > > The token table passed into match_token() must be null-terminated, which > it currently is not in the perf's address filter string parser, as caught > by Vince's perf_fuzzer and KASAN. It doesn't blow up otherwise because of > the alignment padding of the table to the next element in the .rodata, > which is luck.
I can confirm that with this patch applied I no longer get the token-parsing KASAN messages. This is even after I enhanced the perf_fuzzer to generate more realistic address-filters. As an aside, is there any better documentation on what a "proper" address filter looks like? In kernel/events/core.c it says * ACTION RANGE_SPEC * where ACTION is one of the * * "filter": limit the trace to this region * * "start": start tracing from this address * * "stop": stop tracing at this address/region; * RANGE_SPEC is * * for kernel addresses: <start address>[/<size>] * * for object files: <start address>[/<size>]@</path/to/object/file> Does each action always get a range? Are the ranges hex? decimal? can they have a leading 0x? Are the sizes hex? decimal? What's the path to object file for? What kind of object file? Vince
