CVE-2025-26424 AI-generated analysis

platform/frameworks/base, VpnManagerService (system_server, IVpnManager binder)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (7 corrections). Verify against the commit before relying on it.

Adds NETWORK_STACK / MAINLINE_NETWORK_STACK permission enforcement to the four VPN profile store binder methods (get/put/remove/list) in VpnManagerService, which previously had no caller permission check.

Root cause

In services/core/java/com/android/server/VpnManagerService.java the IVpnManager.Stub methods getFromVpnProfileStore, putIntoVpnProfileStore, removeFromVpnProfileStore and listFromVpnProfileStore forwarded directly to mVpnProfileStore.get/put/remove/list without any permission or caller check. Per the commit message these methods are meant only for privileged callers or the owner apps and should not be accessible to apps without the correct permission. Before the fix, any caller able to reach the IVpnManager binder could reach the VPN profile store operations. The bulletin classifies this as information disclosure (ID), High.

How the fix works

• VpnManagerService.java: adds static import of com.android.net.module.util.PermissionUtils.enforceNetworkStackPermission.
• VpnManagerService.getFromVpnProfileStore: calls enforceNetworkStackPermission(mContext) before mVpnProfileStore.get(name).
• VpnManagerService.putIntoVpnProfileStore: calls enforceNetworkStackPermission(mContext) before mVpnProfileStore.put(name, blob).
• VpnManagerService.removeFromVpnProfileStore: calls enforceNetworkStackPermission(mContext) before mVpnProfileStore.remove(name).
• VpnManagerService.listFromVpnProfileStore: calls enforceNetworkStackPermission(mContext) before mVpnProfileStore.list(prefix).
• Each check carries a TODO(b/307903113) saying the NETWORK_STACK permission should be replaced by a proper permission; the commit message describes the restriction as applied because the methods are not yet fully deployed.

Completeness

• All four profile-store entry points on the IVpnManager binder surface (get, put, remove, list) are gated; no profile-store method in the diff is left unguarded.
• The gate is a coarse privileged-caller check (NETWORK_STACK or the mainline network stack permission); the commit's TODO states that a proper permission is still to be adopted.
• No validation of the 'name' or 'prefix' arguments is added; only the caller is restricted.
• Other VpnManagerService methods are not touched by this commit; the material does not show whether they already have checks.

Behavior changes

• Callers of getFromVpnProfileStore, putIntoVpnProfileStore, removeFromVpnProfileStore and listFromVpnProfileStore that do not hold NETWORK_STACK or PERMISSION_MAINLINE_NETWORK_STACK are now rejected by enforceNetworkStackPermission instead of getting the stored data or result; such enforce helpers throw SecurityException (general platform knowledge).
• The VpnManager.putIntoVpnProfileStore wrapper in frameworks/base/core/java/android/net/VpnManager.java (per index search) forwards to the service, so unprivileged callers of it are now rejected.
• VpnManagerServiceTest calls mService.putIntoVpnProfileStore / removeFromVpnProfileStore directly (per index search); these tests may need the permission granted in their setup.

Per major

• Android 14: not affected per the bulletin; at android-security-14.0.0_r29 only 4/8 lines of the patched region are present, so the code differs (the material does not show whether the methods exist there or are already gated).
• Android 15: same fix, cherry-picked into android-security-15.0.0_r8 (commit 1b4ee554c823, Merged-In If6fd058f40da88a4801b59187631e0c68b236ff5); 8/8 lines present at android-security-15.0.0_r17.
• Android 16: not affected per the bulletin; 8/8 lines of the patched region present at android-security-16.0.0_r8.
• Android 17: not affected per the bulletin; 8/8 lines of the patched region present at android-security-17.0.0_r1.

Unknowns

• Why Android 14 is not listed: the material does not show whether the profile-store methods exist in the 14 branch or are already protected there.
• Whether other VpnManagerService / IVpnManager methods beyond these four lack permission checks.
• Whether the follow-up permission referenced by TODO(b/307903113) was landed later.
• How the VpnManagerServiceTest setup grants permissions after the fix.

Back to May 2025 · Findings