The JVM has nothing to do with Android. There is no JVM running android apps.

There was Dalvik VM at one point but now it’s just the Android Runtime.

A very comprehensive SELinux deployment for one.

SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.

The thing is that we could simply split those modules into separate packages

No reason why you couldn’t just `dnf install -y kmod-rxrpc` if for whatever reason you need that.

F44 is safe as the kernel is greater than 6.18.22

Without read permissions you cannot execute the binary, that would not make any sense.

To execute the binary it needs to be read from disk and loaded into memory.

In fact if you have read permissions but not executable permissions on a specific binary then you can still execute it by calling the linker directly /bin/ld.so.1 /path/to/binary (the linker will read and load the binary and then jump to the entry point without an exec() call)

> Without read permissions you cannot execute the binary

This is not correct, as when the binary is setuid-someone-else, you are not the one executing it; they are.

  $ cat hello.c 
  
  #include <stdio.h>
  
  int main(void)
  {
      (void) puts("Hello, world!");
      return 0;
  }
  
  $ clang-21 -Weverything hello.c -o hello
  $ sudo chown root:root hello
  $ sudo chmod 4711 hello
  
  $ ls -l hello
  -rws--x--x 1 root root 16056 Apr 30 22:22 hello
  
  $ ./hello
  Hello, world!
  
  $ id
  uid=1000(aaron) gid=1000(aaron) groups=1000(aaron),27(sudo),46(plugdev),100(users)

Removing world-readability from all setuid-root binaries on the system would be sufficient to kill the PoC script provided for this vulnerability. It would not be sufficient to prevent exploitation though; there are many ways to abuse the ability to write to files you have read access to in order to gain root, for example by using the vulnerability to alter the cached copy of a file in /etc/sudoers.d/, or overwrite /etc/passwd, or /etc/crontab, ... the list goes on.

interesting but in that case no point in keeping the x bit either and suid binaries should just be 4700 ?

If they don't have world-execute permission, an access(2) check for executability would return negative, leading to things like shells not tab-completing it. The kernel would also deny attempting to execute it, as it is not executable for your fsuid.

  $ sudo chmod 4700 hello
  $ ./hello
  bash: ./hello: Permission denied

You need execute access in order to launch it, but in order for it to run, the user it is running as (not you) needs read access; you don't.

this ld.so magic will lose the suid bit

    $ /bin/ld.so `which sudo`
    sudo-rs: sudo must be owned by uid 0 and have the setuid bit set

loader

Disagree because to run the PoC you really ought to understand what it’s doing.

And this code is not readable at all. It is failing at letting people confirm the exploit easily.

>Disagree because to run the PoC you really ought to understand what it’s doing.

that is contained in the report, which will look similar to the blog. the maintainers will have an open line of contact with the reporters as well. the poc is a small part of the entire report. its not like the linux maintainers only received this poc and have to work out the vulnerability from it alone.

>It is failing at letting people confirm the exploit easily.

it confirms the exploit incredibly easy. just run it, and you get confirmation.

what the blog says and what the code does are two different things.

For all I know the blog itself is a honey pot. I need to know what the code does before I run it.

>I need to know what the code does before I run it.

its literally code meant to exploit your system. you should be running it in an environment built for that already.

you dont test exploit pocs on your daily driver.

> you dont test exploit pocs on your daily driver.

Do you just like making fake points and pretending other people said them?

go ahead and explain your point, rather than be cryptic, if you you want to have an actual conversation about it.

you said "I need to know what the code does before I run it.".

you know its an LPE. the mechanisms of the exploit are fully explained. what more do you need to know? please imagine yourself in the position of the kernel security team who would have received this poc in the first place when you answer, because that is the intended context of the poc.

if you think the kernel security team is going to get tripped up over "os as g", you have a crazy low view of the team.

While your at it you can enter your credit card details to see if they've been leaked.

Agreed lmao the PoC itself looks like you’re getting attacked

Which I guess is true but I would like to verify the attack is the intended one

You’d have to reinstall the su binary itself I guess

It just changes the page cache for the su binary, a reboot will revert it.

No need to reboot:

sync && echo 3 >/proc/sys/vm/drop_caches

No, Android doesn’t have suid binaries to exploit like in the PoC

The vulnerability can also be used on any binary that is already running as root and you can open for reading. So yes, any android app can now escalate to root if android has the vulnerable module.

Unfortunately another comment thread here says that it doesn't.

there’s barely any hacking here

the guy found this through looking at the firmware but nmap -p 22 would have also found this

So like the first thing you would do to attack the device

I found an issue exactly like this on an ISP-provided router. I am nowhere near geohot but also didn’t even do as much as the guy in the article lmao

to me this is just normal to do with your devices. I think it’s interesting because it has no fw signing etc and because they left ssh, not because of figuring out how to do the patching.