Merge pull request #363 from m-y-mo/update_kgsl_readme

Update readme

Author: xcorail

SecurityExploits/Android/Qualcomm/CVE-2020-11239/README.md

@@ -2,7 +2,11 @@
 
 The write up can be found [here](https://securitylab.github.com/research/one_day_short_of_a_fullchain_android). This is a bug in the Qualcomm kgsl driver I reported in July 2020. The GitHub Advisory can be found [here](https://securitylab.github.com/advisories/GHSL-2020-375-kgsl). The bug can be used to gain arbitrary kernel code execution, read and write from the untrusted app domain.
 
-The exploit is tested on Samsung Galaxy A71 with firmware version A715FXXU3ATJ2, Baseband A715FXXU3ATI5 and Kernel version 4.14.117-19828683. The offsets in the exploit refers to that version of the firmware. For different models of phones, the macro `DMA_ADDRESS`, which indicates the address of the SWIOTLB buffer, will also need to be changed.
+The exploit is tested on Samsung Galaxy A71 with firmware version A715FXXU3ATJ2, Baseband A715FXXU3ATI5 and Kernel version 4.14.117-19828683. The offsets in the exploit refers to that version of the firmware. For different models of phones, the macro `DMA_ADDRESS`, which indicates the address of the SWIOTLB buffer, will also need to be changed. In the case where the race condition failed regularly, the macro `DELAY` can be adjusted, although the default value seem to work well on different models. It also requires the phone to have more than 4GB of total ram (not free memory), as it needs to be able to allocate ion buffers with addresses higher than 32 bit. Phones with 4GB of ram may be exploitable, although the ion heap spray parameter will need to change and even in that case, the exploit is unlikely to be reliable. I also received some feedback that the compiler and compile options affect the reliability. For reference, I used the following command to compile with clang in ndk-21:
+
+```
+android-ndk-r21d-linux-x86_64/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android30-clang kgsl_exploit_slab_a71.c -o kgsl_exploit_stable
+```
 
 The exploit is reasonably reliable, although it does need to wait a few minutes after start up, after the kernel activities settled down before running.