I'm investigating how to make the IPC transfer a bit more secure on the

src/effects/SkBicubicImageFilter.cpp

Index: src/effects/SkBicubicImageFilter.cpp
diff --git a/src/effects/SkBicubicImageFilter.cpp b/src/effects/SkBicubicImageFilter.cpp
index db8dbfd0286c506b98cc4a58720d5e67820f562d..69d33ea4f07138cc1185049c0430d152e917c700 100644
--- a/src/effects/SkBicubicImageFilter.cpp
+++ b/src/effects/SkBicubicImageFilter.cpp
@@ -99,6 +99,9 @@ bool SkBicubicImageFilter::onFilterImage(Proxy* proxy,
                                     SkScalarMul(SkIntToScalar(src.height()), fScale.fHeight));
     SkIRect dstIRect;
     dstRect.roundOut(&dstIRect);
+    if (dstIRect.isEmpty()) {

[Stephen White, 2013/08/21 20:49:26]

In the belt-and-suspenders department, we should also find out who is
dereferencing the pixels of this zero-size bitmap downstream, and fix that too.

[sugoi, 2013/08/21 21:12:09]

Isn't returning false enough ? It's pretty much the same behavior as failing to
allocate the pixels, a few lines below. And the input isn't 0 sized, it's been
scaled down to anything less than 0.5 in any dimension.

[Stephen White, 2013/08/21 21:23:00]

OK, maybe I'm confused. I thought you said at one point that if you allowed this
(0x0 alloc), the allocation actually "succeeded", but malloc returned you
something you couldn't deref, that blew up in a downstream image filter. That
downstream image filter sounds like it's got a bug, if it's trying to deref a
0x0 buffer.

[sugoi, 2013/08/21 21:34:01]

Ah, ok, I see what you mean. Since the size is 0 x 0, there's no point in trying
to access anything. I'll try to find out where (there must be multiple
occurrences of this) we dereference a pointer before actually entering a loop,
which is potentially accessing invalid memory.

+        return false;
+    }
     result->setConfig(src.config(), dstIRect.width(), dstIRect.height());
     result->allocPixels();
     if (!result->getPixels()) {