KSU bug in granting root for apps on BlissOS

[hmtheboy154]

Please check before submitting an issue

• I have searched the issues and haven't found anything relevant
• I will upload bugreport file in KernelSU Manager - Settings - Report log
• I know how to reproduce the issue which may not be specific to my device

Describe the bug

(This issue may look like #2095, but I can't verify yet)
Currently with latest KSU on BlissOS, tested on kernel 6.1 & 6.6 & 6.9 & 6.11, there are some bugs that I started to notice: While some apps like Aurora Store, Neo Store & FoxLog can be able to grant root and use normally, some are broken in functions or just straight up not working:

• Termux can only be able to go to su if using /system/bin/su, and when in su no $PATH is set other than Termux or KSU own path.
• MiXplorer can't be able to use Allow Root even set with rootexplorer.root or system template. I tried another app Amaze File Manager with their Root Explorer & Use legacy listing for root and it can do things like show the whole /data but can't access anything in /data/app.
• If using another term app like TermOnePlus, it will not working even if using either su or /system/bin/su

All recent BlissOS builds with KernelSU 1.0.1 have this issue. And currently they are on kernel 6.1. I bumped kernel to 6.6 to test locally and it show the same behaviour. For newer kernel that are on stable branch, the same behaviour can be seen on this PR I made . Recently I do try to build for kernel 6.11 and it also have the same behaviour (here is my fork for 6.11).

To Reproduce

• For kernel 6.1 + KSU 1.0.1 testing, download any latest stable build of BlissOS
• For kernel 6.1 + KSU 0.9.2 testing, download older builds such as 16.9.6, 15.9.1 or 14.10.2
• For kernel 6.9 + KSU 0.9.2 testing, download latest BlissOS Zenith (16.9.6)
• For kernel 6.6 + KSU 1.0.1 or kernel 6.11 + KSU 1.0.1 tesing, it's currently WIP and still being worked on. If anyone ask, I'll provide.

Expected behavior

Apps can be able to grant root and work as expected

Screenshots

An example of Termux can't use su can be seen here : #1785 (comment)

Logs

will provide soon

Device info

• Device: Generic x86_64-v2 devices
• OS Version: Android 11/12.1/13/14
• KernelSU Version: 1.0.1 (latest main)
• Kernel Version: 6.1.x + 6.6.x + 6.11.x

Additional context

One last thing that I tested is to downgrade to 0.9.2 as some people suggested , it only work with kernel 6.1 & 6.6. If you port it to higher kernel like 6.9, it will have the exact same issue.

[hansalemaos]

Same problem here. It seems like something in the shell is "cloaking" the su call
If I pipe something to toybox, I can call su.

Maybe it is releated to:

# interesting detail of KernelSU - it doesn't actually place a su file in
# /system/bin, but hook execve(2) call in kernel to redirect it to kernel
# impl when executing /system/bin/su.

termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R9

[tiann]

exec strace su and observe the output

[Xtr126]

/system/bin/strace su says faccessat(AT_FDCWD, "/system/bin/su", X_OK) = -1 ENOENT (No such file or directory)

strace.txt

[tiann]

It seems that this kprobe failed: https://github.com/tiann/KernelSU/blob/main/kernel/sucompat.c#L265
is there any dmesg log?

[Xtr126]

Looks like it has succeeded
dmesg:

[    0.621438] KernelSU: sucompat: execve_kp: 0
[    0.622879] KernelSU: sucompat: newfstatat_kp: 0
[    0.624354] KernelSU: sucompat: faccessat_kp: 0
[    0.626269] KernelSU: sucompat: devpts_kp: 0
[    0.626359] KernelSU: ksud: execve_kp: 0
[    0.628102] KernelSU: ksud: vfs_read_kp: 0
[    0.630275] KernelSU: ksud: input_event_kp: 0
[   19.383064] KernelSU: on_post_fs_data!
[   19.383068] KernelSU: unregister input kprobe: 1!
[   19.383072] KernelSU: devpts sid: 741
[   19.383073] KernelSU: unregister execve kprobe: 1!

dmesg.txt

[hmtheboy154]

[   19.383068] KernelSU: unregister input kprobe: 1!
[   19.383072] KernelSU: devpts sid: 741
[   19.383073] KernelSU: unregister execve kprobe: 1!

this indicate it failed to unregister ?

[hmtheboy154]

@tiann I just remember something: When I test #2041 , I test it in kernel 6.1.84. And it work perfectly fine from granting apps to using modules. After the PR got merged I upstream the kernel and then I have reports about KSU bugging.
So something in the upstream kernel is causing this. Which explain why stable branch affected the same even if using 0.9.2.

I am currently narrowing down to see up until which version does the bug happen, currently it's around 6.1.84 ~ 6.1.89

[hmtheboy154]

6.1.85 is when it happen

[Xtr126]

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

[hmtheboy154]

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test
https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

[Xtr126]

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

I have tested 6.1.84 and can confirm everything works there, but I meant in the builds with newer kernel, modules don't work or even get mounted.

[hmtheboy154]

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

I have tested 6.1.84 and can confirm everything works there, but I meant in the builds with newer kernel, modules don't work or even get mounted.

try to get log, maybe there are more clue than faccessat() is broken

[Xtr126]

I tried even with loglevel=7 and checked in logcat but no clue yet. The dmesg doesn't differ much from that of the working version (6.1.84). But I saw that KernelSU has CONFIG_KSU_DEBUG, it could possibly help in getting more logs.

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

I have tested 6.1.84 and can confirm everything works there, but I meant in the builds with newer kernel, modules don't work or even get mounted.

try to get log, maybe there are more clue than faccessat() is broken

[hmtheboy154]

@tiann found the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2

Revert this and it KSU work as expected now. And I even test this on kernel 6.11.2

[hmtheboy154]

so this seems affected all x86 platform not just Android-x86 based like us

[tiann]

please check cat /proc/kallsyms and dump the symbols

[hmtheboy154]

please check cat /proc/kallsyms and dump the symbols

when KSU broke or when it's working ?

[tiann]

please check cat /proc/kallsyms and dump the symbols

when KSU broke or when it's working ?

broken, and the kernel image

[hmtheboy154]

kallsyms.txt

and the kernel image

kernel.zip

[hmtheboy154]

So as a workaround, I saw this patch in LKML:
https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/

I applied it and test on my kernel 6.11 and it's working so far
android-generic/kernel-zenith@0c2e19c

However, I still think that we should fix KSU itself.

[hmtheboy154]

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/

I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c

However, I still think that we should fix KSU itself.

Build this on 6.1 requires disabling BHI mitigations by setting spectre_bhi=off though

[hmtheboy154]

@tiann I found this post : https://blog.hakuya.moe/post/13

[hmtheboy154]

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/

I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c

However, I still think that we should fix KSU itself.

Finalize the temp fix: android-generic/kernel-zenith@5648396

Because I don't want to fully revert, I put the option under a cmdline syscall_hardening=off . Until there's a new way to hook into x86_64 syscall, I guess this is what I can do.

[hansalemaos]

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/
I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c
However, I still think that we should fix KSU itself.

Finalize the temp fix: android-generic/kernel-zenith@5648396

Because I don't want to fully revert, I put the option under a cmdline syscal_hardening=off . Until there's a new way to hook into x86_64 syscall, I guess this is what I can do.

Nice, any idea when the updated BlissOs will be online?

[hmtheboy154]

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/
I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c
However, I still think that we should fix KSU itself.

Finalize the temp fix: android-generic/kernel-zenith@5648396
Because I don't want to fully revert, I put the option under a cmdline syscal_hardening=off . Until there's a new way to hook into x86_64 syscall, I guess this is what I can do.

Nice, any idea when the updated BlissOs will be online?

updated, please check

[hansalemaos]

Thx, I will check that today!!

[hansalemaos]

Did not work :( Only with the Toybox trick I used before. I downloaded Bliss-v16.9.7-x86_64-OFFICIAL-gapps-20241011.iso

[hmtheboy154]

Did not work :( Only with the Toybox trick I used before. I downloaded Bliss-v16.9.7-x86_64-OFFICIAL-gapps-20241011.iso

have you boot with syscall_hardening=off cmdline yet ?

[hansalemaos]

nope, I should have read your old post, let me try

[hansalemaos]

WORKING! THX SO MUCH!