Respect the kasan_disable & kasan_enable functions

[qazwsxedcrfvtg14]

Some kernel codes would use kasan_disable_current & kasan_enable_current to disable & enable the kasan. Respecting it could prevent the false alarm in the fuzzing report.

[tklengyel]

I don't think this PR accomplishes what you are trying to do. Once any sink is hit the execution is interrupted and the fuzzer will go to the next input. If I understand correctly you are discovering code where kasan_report is called but kasan is disabled so you want the execution to continue beyond kasan_report. If that's the case simply patch out the call to kasan_report on the sink VM using rwmem so that call to kasan_report doesn't happen.

[qazwsxedcrfvtg14]

In our cases, seems it's hard to patch out the call to kasan_report: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/kernel/v5.4/mm/slub.c;drc=4f69c8930674add482d8b79b6279bed8bc6d7d69;l=489

I rewrite the change with this VMI event response to prevent the sink interrupted: VMI_EVENT_RESPONSE_EMULATE | VMI_EVENT_RESPONSE_SET_EMUL_INSN

[tklengyel]

I generally find having an optional sink callback would be fine that determines whether the sink should stop the execution and if it does whether report a crash or not (like what the current ignore field does).

For your particular issue I would suggest instead of trying to keep track of various kasan_enable/disable calls by tracing them, to just have a single kasan_report callback that would read the actual state of kasan out of the kernel's memory. Would be a lot simpler and less error prone. Remember, the kernel already has that information kept in memory, we don't need to trace these functions to figure out the state. Just have to figure out where the information is in memory and read it when kasan_report trips.

[tklengyel]

Thanks, looks good, I'll make a couple minor changes after merging but overall this is good!