The issue reported on lowlevel.fun [0] and discussed on GrapheneOS forums [1] does seem like a security issue. It isn't clear why engineers in charge would mark it infeasible as the breach demonstrates more than one failure.

1. A new (albeit "hidden" [2]) network API registerQuicConnectionClosePayload(fd, payload) lets a process set any byte array for the OS to send on its behalf.

2. No ("panaroid networking") permission checks against the calling uid/process when sending that byte array out on a OS-owned UDP socket.

3. Bypassing ("panaroid android") permission checks [3] by simply calling network-related syscalls (or libc/bionic functions) as opposed to Android SDK APIs.

These steps essentially amount to app sandbox escape (2,3) and privilege escalation (1,2). I am utterly confused why the Android security team at Google won't take this more seriously.

[0] https://lowlevel.fun/posts/tiny-udp-cannon-android-vpn-bypas...

[1] https://discuss.grapheneos.org/d/35152-android-always-on-vpn...

[2] In as much the code mmap'd into your own process can be "hidden" away. For their exploit though, the author cleverly abuses Binder IPC primitives to reach the "hidden" parts.

[3] This bypass probably only works for this one scenario because of #2.