[SCM] WebKit Debian packaging branch, debian/experimental, updated. upstream/1.3.3-9427-gc2be6fc
tony at chromium.org
tony at chromium.org
Wed Dec 22 12:57:20 UTC 2010
The following commit has been merged in the debian/experimental branch:
commit 9fd7c6437611f08b72f31c6286b602d7f11bd90a
Author: tony at chromium.org <tony at chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date: Thu Sep 2 22:57:49 2010 +0000
2010-09-02 Adam Langley <agl at chromium.org>
Reviewed by Adam Barth.
[chromium] fix memory corruption in Khmer rendering.
* fast/text/khmer-crash-expected.txt: Added.
* fast/text/khmer-crash.html: Added.
2010-09-02 Adam Langley <agl at chromium.org>
Reviewed by Adam Barth.
[chromium] fix memory corruption in Khmer rendering.
https://bugs.webkit.org/show_bug.cgi?id=44960
Test: fast/text/khmer-crash.html
* platform/graphics/chromium/FontLinux.cpp:
(WebCore::TextRunWalker::shapeGlyphs):
The Khmer shaper has a bug where it would request larger output
buffers, but request a zero increase in size. Because of this we add
one to the requested size.
(WebCore::TextRunWalker::setGlyphXPositions):
The Khmer shaper is outputing cluster logs which suggest that some
output glyphs appear from nowhere (i.e. have no input codepoints). I
don't know Khmer, so maybe that's correct, but it broke the
assumptions of this code, causing a read out-of-bounds.
* platform/graphics/chromium/HarfbuzzSkia.cpp:
(WebCore::stringToGlyphs):
The Harfbuzz interfaces aren't documented, but it appears that the
output array to stringToGlyphs isn't sized and that Harfbuzz expects
us to detect when the input is too long.
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@66689 268f45cc-cd09-0410-ab3c-d52691b4dbfc
diff --git a/LayoutTests/ChangeLog b/LayoutTests/ChangeLog
index 8aec261..274a332 100644
--- a/LayoutTests/ChangeLog
+++ b/LayoutTests/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-02 Adam Langley <agl at chromium.org>
+
+ Reviewed by Adam Barth.
+
+ [chromium] fix memory corruption in Khmer rendering.
+
+ * fast/text/khmer-crash-expected.txt: Added.
+ * fast/text/khmer-crash.html: Added.
+
2010-09-02 Zhenyao Mo <zmo at google.com>
Unreviewed, add two failing tests (http/tests/inspector/console-xhr-logging.html and http/tests/inspector/resource-har-conversion.html) to platform/chromium/test_expectations.txt.
diff --git a/LayoutTests/fast/text/khmer-crash-expected.txt b/LayoutTests/fast/text/khmer-crash-expected.txt
new file mode 100644
index 0000000..aa73f67
--- /dev/null
+++ b/LayoutTests/fast/text/khmer-crash-expected.txt
@@ -0,0 +1,2 @@
+This test checks that rendering of Khmer text does not crash. The test passes if it does not crash.
+ប្រឆាំងនឹងភាពល្ងង់ខ្លៅ
diff --git a/LayoutTests/fast/text/khmer-crash.html b/LayoutTests/fast/text/khmer-crash.html
new file mode 100644
index 0000000..df4badd
--- /dev/null
+++ b/LayoutTests/fast/text/khmer-crash.html
@@ -0,0 +1,21 @@
+<!DOCTYPE html>
+<html dir="ltr" lang="km">
+<head>
+<meta charset="UTF-8" />
+<title>តូបសៀវភៅ | ប្រឆាំងនឹងភាពល្ងង់ខ្លៅ</title>
+</head>
+ <div>This test checks that rendering of Khmer text does not crash. The test
+ passes if it does not crash.</div>
+ <div id="site-description">ប្រឆាំងនឹងភាពល្ងង់ខ្លៅ</div>
+</body>
+
+<script>
+function runTest() {
+ if (window.layoutTestController)
+ layoutTestController.dumpAsText();
+ var div = document.getElementById("site-description");
+ window.getSelection().setBaseAndExtent(div, 0, div, 1);
+}
+runTest();
+</script>
+</html>
diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog
index 1f514c1..b1c6c8b 100644
--- a/WebCore/ChangeLog
+++ b/WebCore/ChangeLog
@@ -1,3 +1,29 @@
+2010-09-02 Adam Langley <agl at chromium.org>
+
+ Reviewed by Adam Barth.
+
+ [chromium] fix memory corruption in Khmer rendering.
+
+ https://bugs.webkit.org/show_bug.cgi?id=44960
+
+ Test: fast/text/khmer-crash.html
+
+ * platform/graphics/chromium/FontLinux.cpp:
+ (WebCore::TextRunWalker::shapeGlyphs):
+ The Khmer shaper has a bug where it would request larger output
+ buffers, but request a zero increase in size. Because of this we add
+ one to the requested size.
+ (WebCore::TextRunWalker::setGlyphXPositions):
+ The Khmer shaper is outputing cluster logs which suggest that some
+ output glyphs appear from nowhere (i.e. have no input codepoints). I
+ don't know Khmer, so maybe that's correct, but it broke the
+ assumptions of this code, causing a read out-of-bounds.
+ * platform/graphics/chromium/HarfbuzzSkia.cpp:
+ (WebCore::stringToGlyphs):
+ The Harfbuzz interfaces aren't documented, but it appears that the
+ output array to stringToGlyphs isn't sized and that Harfbuzz expects
+ us to detect when the input is too long.
+
2010-09-02 Adam Roben <aroben at apple.com>
Fill the scroll corner with white when shouldPaintCustomScrollbars is
diff --git a/WebCore/platform/graphics/chromium/FontLinux.cpp b/WebCore/platform/graphics/chromium/FontLinux.cpp
index ec79b82..e1c86a2 100644
--- a/WebCore/platform/graphics/chromium/FontLinux.cpp
+++ b/WebCore/platform/graphics/chromium/FontLinux.cpp
@@ -499,7 +499,11 @@ private:
// We overflowed our arrays. Resize and retry.
// HB_ShapeItem fills in m_item.num_glyphs with the needed size.
deleteGlyphArrays();
- createGlyphArrays(m_item.num_glyphs);
+ // The |+ 1| here is a workaround for a bug in Harfbuzz: the Khmer
+ // shaper (at least) can fail because of insufficient glyph buffers
+ // and request 0 additional glyphs: throwing us into an infinite
+ // loop.
+ createGlyphArrays(m_item.num_glyphs + 1);
}
}
@@ -523,7 +527,11 @@ private:
double advance = truncateFixedPointToInteger(m_item.advances[i]);
unsigned glyphIndex = m_item.item.pos + logClustersIndex;
- if (isWordBreak(glyphIndex, isRTL)) {
+ // The first half of the conjuction works around the case where
+ // output glyphs aren't associated with any codepoints by the
+ // clusters log.
+ if (glyphIndex < m_item.num_glyphs
+ && isWordBreak(glyphIndex, isRTL)) {
advance += m_wordSpacingAdjustment;
if (m_padding > 0) {
@@ -547,7 +555,7 @@ private:
while (logClustersIndex > 0 && logClusters()[logClustersIndex] == i)
logClustersIndex--;
} else {
- while (logClustersIndex < m_item.num_glyphs && logClusters()[logClustersIndex] == i)
+ while (logClustersIndex < m_item.item.length && logClusters()[logClustersIndex] == i)
logClustersIndex++;
}
diff --git a/WebCore/platform/graphics/chromium/HarfbuzzSkia.cpp b/WebCore/platform/graphics/chromium/HarfbuzzSkia.cpp
index 4fd3ba0..59e8122 100644
--- a/WebCore/platform/graphics/chromium/HarfbuzzSkia.cpp
+++ b/WebCore/platform/graphics/chromium/HarfbuzzSkia.cpp
@@ -38,6 +38,7 @@
#include "SkPath.h"
#include "SkPoint.h"
#include "SkRect.h"
+#include "SkUtils.h"
extern "C" {
#include "harfbuzz-shaper.h"
@@ -61,6 +62,15 @@ static HB_Bool stringToGlyphs(HB_Font hbFont, const HB_UChar16* characters, hb_u
font->setupPaint(&paint);
paint.setTextEncoding(SkPaint::kUTF16_TextEncoding);
+
+ unsigned codepoints = 0;
+ for (hb_uint32 i = 0; i < length; i++) {
+ if (!SkUTF16_IsHighSurrogate(characters[i]))
+ codepoints++;
+ if (codepoints > *glyphsSize)
+ return 0;
+ }
+
int numGlyphs = paint.textToGlyphs(characters, length * sizeof(uint16_t), reinterpret_cast<uint16_t*>(glyphs));
// HB_Glyph is 32-bit, but Skia outputs only 16-bit numbers. So our
--
WebKit Debian packaging
More information about the Pkg-webkit-commits
mailing list