On Sun, Nov 22, 2015 at 3:32 PM, Rainer Weikusat <rweiku...@mobileactivedefense.com> wrote: > Dmitry Vyukov <dvyu...@google.com> writes: >> Hello, >> >> On commit f2d10565b9bdbb722bd43e6e1a759eeddb9645c8 (Nov 20). >> >> The following program triggers use-after-free: >> >> // autogenerated by syzkaller (http://github.com/google/syzkaller) >> #include <syscall.h> >> #include <string.h> >> #include <stdint.h> >> #include <pthread.h> >> >> void *thread(void *p) >> { >> syscall(SYS_write, (long)p, 0x2000278ful, 0x1ul, 0, 0, 0); >> return 0; >> } > > [...] > > >> long r1 = syscall(SYS_socketpair, 0x1ul, 0x3ul, 0x0ul, > > [...] > >> long r5 = syscall(SYS_close, r2, 0, 0, 0, 0, 0); >> pthread_t th; >> pthread_create(&th, 0, thread, (void*)(long)r3); > > [...] > >> long r21 = syscall(SYS_ppoll, 0x20000ffful, 0x3ul, 0x20000ffcul, >> 0x20000ffdul, 0x8ul, 0); >> return 0; >> } > > That's one of the already known sequences for triggering this issue: The > close will clear the peer pointer of the closed socket, hence, the 2nd > sock_poll_wait will be called by unix_dgram_poll. The write will > execute unix_dgram_sendmsg which detects that the peer is dead and > disconnects from it, causing the corresponding structures to be freed > despite they're still used. > > NB: I didn't execute this but I spend a fair amount of time with the > af_unix.c code during the last couple of weeks and consider myself > "reasonably familiar" with it and that's IMO what should happen here.
I have not read the code. But I just want to point out that all 3 reports are different. For example, in the first one, ppoll both frees the object and then accesses it. That is, it is not write that frees the object. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/