tags 401660 patch
thanks
Given this bug's apparent RC status, we still need a fix for exiv2 0.10 for
etch.
I believe I've isolated the relevant fix for this bug based on the upstream
0.12 changelog. Gregor, could you check whether the attached patch, applied
to exiv2 0.10, fixes the crash for you? If not, could you please forward an
example jpeg that triggers the crash?
At this point, I'm inclined to say that the main reason for treating this
bug as RC is that crashes on invalid input are often exploitable.
Ungraceful handling of invalid files doesn't itself make a package unusable,
so if this bug were known to not be exploitable, I would be inclined to
downgrade it.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
diff -u exiv2-0.10/debian/changelog exiv2-0.10/debian/changelog
--- exiv2-0.10/debian/changelog
+++ exiv2-0.10/debian/changelog
@@ -1,3 +1,12 @@
+exiv2 (0.10-1.4) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * High-urgency upload for RC bugfix.
+ * Fix crash from trying to read too many entries in the case of a corrupted
+ exif header; closes: #401660.
+
+ -- Steve Langasek <[EMAIL PROTECTED]> Mon, 8 Jan 2007 02:37:55 -0800
+
exiv2 (0.10-1.3) unstable; urgency=low
* NMU.
only in patch2:
unchanged:
--- exiv2-0.10.orig/src/ifd.cpp
+++ exiv2-0.10/src/ifd.cpp
@@ -309,11 +309,22 @@
Ifd::PreEntries preEntries;
if (len < o + 2) rc = 6;
+ int n = 0;
if (rc == 0) {
offset_ = start - shift;
- int n = getUShort(buf + o, byteOrder);
+ n = getUShort(buf + o, byteOrder);
o += 2;
-
+ // Sanity check with an "unreasonably" large number
+ if (n > 256) {
+#ifndef SUPPRESS_WARNINGS
+ std::cerr << "Error: "
+ << "Directory " << ExifTags::ifdName(ifdId_) << " with "
+ << n << " entries considered invalid; not read.\n";
+#endif
+ rc = 6;
+ }
+ }
+ if (rc == 0) {
for (int i = 0; i < n; ++i) {
if (len < o + 12) {
#ifndef SUPPRESS_WARNINGS
