From 5a8a1151e267b29978f219f9569fdfc5e74cc210 Mon Sep 17 00:00:00 2001 From: Christopher Tate Date: Thu, 10 Sep 2009 16:08:47 -0700 Subject: Try not to crash the system server because of corrupt restore data When we're about to allocate an array based on the restore data for purposes of unflattening a signature block, don't automatically assume that it's valid. If it's corrupt [and we've seen this in practice] we can wind up trying to allocate an array with 1.8 million objects, and throw an OutOfMemoryError, bringing down the system. This change arbitrarily decides that no package should have more than 20 signatures in its block, and aborts the restore if the metadata is thus revealed to be corrupt. --- services/java/com/android/server/PackageManagerBackupAgent.java | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/services/java/com/android/server/PackageManagerBackupAgent.java b/services/java/com/android/server/PackageManagerBackupAgent.java index 786f42305c96..772ddeb13fec 100644 --- a/services/java/com/android/server/PackageManagerBackupAgent.java +++ b/services/java/com/android/server/PackageManagerBackupAgent.java @@ -327,6 +327,13 @@ public class PackageManagerBackupAgent extends BackupAgent { try { int num = in.readInt(); Log.v(TAG, " ... unflatten read " + num); + + // Sensical? + if (num > 20) { + Log.e(TAG, "Suspiciously large sig count in restore data; aborting"); + throw new IllegalStateException("Bad restore state"); + } + sigs = new Signature[num]; for (int i = 0; i < num; i++) { int len = in.readInt(); -- cgit v1.2.3-59-g8ed1b