Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions about static analysis #10

Open
opc0nt7 opened this issue Aug 21, 2019 · 1 comment
Open

Questions about static analysis #10

opc0nt7 opened this issue Aug 21, 2019 · 1 comment

Comments

@opc0nt7
Copy link

opc0nt7 commented Aug 21, 2019

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:

  1. 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/
  2. 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

@lifeasageek
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants