[lambdasprocket]

No description provided.

[artmetla]

Please have a look at the comment and fix "--vuln-trigger"

[artmetla]

@lambdasprocket Could you have one more look at --vuln-trigger? Looks like it's not working like it should?

The error we get in vuln-verify is:

terminate called after throwing an instance of 'ExpKitError'
  what():  symbol (__do_sys_kexec_file_load) is not available for the target
Aborted

[koczkatamas]

Hey! Is there any update here?

[lambdasprocket]

Hey! Is there any update here?

Hi!

I'm not sure what you want me to do here. The exploit uses libXDK (per your requirements) for many things, some as basic as object sizes (e.g. simple_xattr) in the allocation primitive.
To completely avoid using libXDK on "--vuln-trigger" would mean adding tens of "if" statements to skip parts of the exploit that allocate memory, prepare payloads etc, which would reduce exploit readability.
And even if I do that, verify won't work anyway because under KASAN execution speed is different and timings used to trigger race condition will be incorrect.

Please let me know how I should proceed.

[matrizzo]

Presumably you don't need to set up reclaims/spray allocations with a precise size etc just to trigger a KASAN bug report though? It sounds to me like you should be able to do that without all the information from kernelXDK.

[lambdasprocket]

Presumably you don't need to set up reclaims/spray allocations with a precise size etc just to trigger a KASAN bug report though? It sounds to me like you should be able to do that without all the information from kernelXDK.

Ok, I've fixed the issue with missing symbols.
It turns out that libxdk throws exception only for getSymbolOffset() and returns zero for getStructSize(), which is strange, but simplifies things in this case.