Open opc0nt7 opened 5 years ago
Hello,
For the static analysis thing, it's difficult to know what went wrong from your side. We will be releasing the new version of Razzer (which replaces LLVMLinux with Clang for the static analysis), and that will give us more stable static analysis results.
Digging back to our previous running result, the log reproducing the n_hdlc bug is as follows (working on kernel v4.8).
# scheduler executing program 0
# Cov 817f95cb , Addr 817f95eb , Idx 12
# Cov 817f8288 , Addr 817f82ba , Idx 13
# Loc0 drivers/tty/n_hdlc.c:218:0 , Loc1 drivers/tty/n_hdlc.c:408:0
# Hash f9d726e25fad514c , Sched 1
mmap(&(0x7f0000000000/0xa000)=nil, 0xa000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
r0 = openat$ptmx(0xffffffffffffff9c, &(0x7f0000002000)="2f6465762f70746d7800", 0x201, 0x0)
ioctl$TIOCSETD(r0, 0x5423, &(0x7f0000007000-0x4)=0x10000000d)
mmap(&(0x7f000000a000/0x1000)=nil, 0x1000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
mmap(&(0x7f000000b000/0x1000)=nil, 0x1000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
openat$ptmx(0xffffffffffffff9c, &(0x7f000000c000-0xa)="2f6465762f70746d7800", 0x100, 0x0)
r1 = openat$ptmx(0xffffffffffffff9c, &(0x7f000000b000-0xa)="2f6465762f70746d7800", 0x4080, 0x0)
ioctl$TCXONC(r1, 0x540a, 0x1)
ioctl$TCXONC(r0, 0x540a, 0x0)
mmap(&(0x7f000000a000/0x1000)=nil, 0x1000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
write(r0, &(0x7f0000001000)="6e", 0x1)
ioctl$TIOCSETD(r0, 0x5423, &(0x7f0000008000)=0xdd38)
ioctl$TCFLSH(r0, 0x540b, 0x2)
ioctl$TCXONC(r0, 0x540a, 0x1)
mmap(&(0x7f000000a000/0x1000)=nil, 0x1000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
r2 = openat$ptmx(0xffffffffffffff9c, &(0x7f000000b000-0xa)="2f6465762f70746d7800", 0x200, 0x0)
mmap(&(0x7f000000b000/0x1000)=nil, 0x1000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
mmap(&(0x7f000000c000/0x1000)=nil, 0x1000, 0x3, 0x32, 0xffffffffffffffff, 0x0)
ioctl$TIOCSETD(r2, 0x5423, &(0x7f000000d000-0x4)=0xed6)
openat$ptmx(0xffffffffffffff9c, &(0x7f000000b000)="2f6465762f70746d7800", 0x0, 0x0)
I don't have the log for KASAN: null-ptr-deref Write in binder_update_page_range
, so let me ask Dae. R about it later.
Thanks Byoungyoung
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