Hello, thank you for your hard working.
I have read the paper and want to reproduce CVE-2017-2636. What I have done as belows:
- Roll back the patch "tty: n_hdlc: get rid of racy n_hdlc.tbuf" from kernel-4.18-rc3, I have modified the codes in razzer/kernel-repo/static_analysis/kernel_v4.18-rc3/
- Enable CONFIG_N_HDLC=y in razzer/tools/llvmlinux/targets/x86_64/configs/config-v4.18-rc3-syzkaller
After the instructions mentioned in docs/static-analysis.md, the mempair file has been generated. What I expected according to the paper is that I can found some strings in mempair file just like
drivers/tty/n_hdlc.c:440:x drivers/tty/n_hdlc.c:216:x W R
But there is nothing related to this.
I have found that the issue "KASAN: null-ptr-deref Write in binder_update_page_range
" reported by razzer is also exists in kernel-v4.17 and I tried the static analysis on kernel-4.17, but still found nothing related to binder in mempair.
Since I am not familiar with SVF, I'm not sure which part I have done was wrong. It will be so nice of you to give me some hints.
BTW, I'm sure that the line number of code is same with paper.
Thanks
Hello, thank you for your hard working.
I have read the paper and want to reproduce CVE-2017-2636. What I have done as belows:
After the instructions mentioned in docs/static-analysis.md, the mempair file has been generated. What I expected according to the paper is that I can found some strings in mempair file just like
But there is nothing related to this.
I have found that the issue "KASAN: null-ptr-deref Write in binder_update_page_range
" reported by razzer is also exists in kernel-v4.17 and I tried the static analysis on kernel-4.17, but still found nothing related to binder in mempair.
Since I am not familiar with SVF, I'm not sure which part I have done was wrong. It will be so nice of you to give me some hints.
BTW, I'm sure that the line number of code is same with paper.
Thanks