Just an update…
I was seeing buffer overflow errors reported by code analysis on some of my TraceLogger calls to TraceLoggingWriteActivity. The code seemed to compile and worked, but could not pass code analysis.
I now believe the issue is stimulated by an event parameters that called KeGetCurrentProcessor(), which returns a ULONG. I added a variable, to which I assigned the processor index, and passed that variable in the event instead of the call to the function, and the errors went away. It looks like the parameter building macros always want to take the address of the parameter, even though they claim to take values, and am puzzled how it thought it was able to take the address of the function return value.
I looked at the TraceLogger macros and am not clear what the real problem was, but somehow using the value returning function instead of an addressable variable causes the event data building macros to confuse code analysis. I looked at the preprocessed code, and didn’t actually see where the compile time event structure was indexing past it’s bounds. It did want to pass the value as a const& parameter (C code was in .cpp suffix files, so compiled as C++) to a function that built each parameter.
After a few more experiments. I have a super simple repro case. It only causes a code analysis failure if the source is a .cpp file. The error reads
C6386 Buffer overrun while writing to ‘_TlgData’: the writable size is ‘64’ bytes, but ‘80’ bytes might be written.
Using an event like follows stimulates the error:
TraceLoggingWrite(
traceLogger,
“MyEvent1”,
TraceLoggingString(“aString”, “str”),
TraceLoggingUInt32(KeGetCurrentProcessorNumber(), “anInt32”));
This might be a bug TraceLoggingProvider.h, or it might be a code analyzer bug in the VS 2015 Update1 tools. I am getting some other code analysis “buffer overrun” errors, in code that really seems like it doesn’t have a buffer overrun. For example, it does an ExAllocatePoolWithTag, which then accesses the memory block with a pointer using array subscripts. Code analysis reports something like sizeof(foo_t) * elements byte writable but 384 bytes written, so I added 1024 to the allocation, and it still says the same thing. Clearly code analysis is not using the allocation size. If I change the code to be functionally identical but using pointer math instead of array subscripts, code analysis is happy. The issue seen with the above TraceLoggingWrite also fails on an array subscript, when you dig down into all the macros.
Jan
From: > on behalf of Jan Bottorff >
Reply-To: Windows List >
Date: Saturday, February 13, 2016 at 2:32 PM
To: Windows List >
Subject: [ntdev] TraceLogger and code analysis buffer overflows
I recently started using tracelogger tracing (traceloggingprovider.h) and ran code analysis on my project yesterday. Some of the tracepoints are reported as writing 16 bytes (the sizeof of a GUID) more than some buffer size. What’s odd is it doesn’t seem like it’s all tracepoints, and no pattern of parameters immediately was apparent. I am calling TraceLoggingWriteActivity instead of TraceLoggerWrite because activity ids are extremely useful when looking at the traces, but this may be less common. Has anybody else seen this?
This may be a show stopper for using tracelogger, or I may have to edit traceloggerprovider.h myself to fix it. Editing a Microsoft provided file is never a good idea, but would prefer not to declare traceloggerprovider.h unusable. I’m going to see if I can make a do nothing driver repro case. As tracelogger is implemented as C preprocessor macros, looking at the preprocessor output should show what’s happening. Google searches didn’t turn up anybody else reporting this or workarounds.
Jan
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>