Back fill release notes for #7864

- Back fill release notes for 3.1.1
- Add credits to 2.3.2, 2.5.2

docs/releasenotes/2.3.2.rst

@@ -10,3 +10,5 @@ Security
 ``PIL/IcnsImagePlugin.py`` in Python Imaging Library (PIL) and Pillow before 2.3.2 and
 2.5.x before 2.5.2 allows remote attackers to cause a denial of service via a crafted
 block size.
+
+Found and reported by Andrew Drake of dropbox.com

docs/releasenotes/2.5.2.rst

@@ -10,3 +10,5 @@ Security
 ``PIL/IcnsImagePlugin.py`` in Python Imaging Library (PIL) and Pillow before 2.3.2 and
 2.5.x before 2.5.2 allows remote attackers to cause a denial of service via a crafted
 block size.
+
+Found and reported by Andrew Drake of dropbox.com

docs/releasenotes/3.1.1.rst

@@ -4,81 +4,9 @@
 Security
 ========
 
-:cve:`2016-0740`: Buffer overflow in TiffDecode.c
+:cve:`2016-0775`: Fix buffer overflow
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Pillow 3.1.0 and earlier when linked against
+Buffer overflow in the ImagingFliDecode function in ``libImaging/FliDecode.c``
-libtiff >= 4.0.0 on x64 may overflow a buffer when reading a
+in Pillow before 3.1.1 allows remote attackers to cause a denial of service
-specially crafted tiff file.
+(crash) via a crafted FLI file.
-
-Specifically, libtiff >= 4.0.0 changed the return type of
-``TIFFScanlineSize`` from ``int32`` to machine dependent
-``int32|64``. If the scanline is sized so that it overflows an
-``int32``, it may be interpreted as a negative number, which will then
-pass the size check in ``TiffDecode.c`` line 236. To do this, the
-logical scanline size has to be > 2gb, and for the test file, the
-allocated buffer size is 64k against a roughly 4gb scan line size. Any
-image data over 64k is written over the heap, causing a segfault.
-
-This issue was found by security researcher FourOne.
-
-:cve:`2016-0775`: Buffer overflow in FliDecode.c
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In all versions of Pillow, dating back at least to the last PIL 1.1.7
-release, FliDecode.c has a buffer overflow error.
-
-Around line 192:
-
-.. code-block:: c
-
-  case 16:
-      /* COPY chunk */
-      for (y = 0; y < state->ysize; y++) {
-          UINT8* buf = (UINT8*) im->image[y];
-          memcpy(buf+x, data, state->xsize);
-          data += state->xsize;
-      }
-      break;
-
-
-The memcpy has error where ``x`` is added to the target buffer
-address. ``X`` is used in several internal temporary variable roles,
-but can take a value up to the width of the image.  ``Im->image[y]``
-is a set of row pointers to segments of memory that are the size of
-the row.  At the max ``y``, this will write the contents of the line
-off the end of the memory buffer, causing a segfault.
-
-This issue was found by Alyssa Besseling at Atlassian.
-
-:cve:`2016-2533`: Buffer overflow in PcdDecode.c
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In all versions of Pillow, dating back at least to the
-last PIL 1.1.7 release, ``PcdDecode.c`` has a buffer overflow error.
-
-The ``state.buffer`` for ``PcdDecode.c`` is allocated based on a 3
-bytes per pixel sizing, where ``PcdDecode.c`` wrote into the buffer
-assuming 4 bytes per pixel. This writes 768 bytes beyond the end of
-the buffer into other Python object storage. In some cases, this
-causes a segfault, in others an internal Python malloc error.
-
-Integer overflow in Resample.c
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If a large value was passed into the new size for an image, it is
-possible to overflow an ``int32`` value passed into malloc.
-
-.. code-block:: c
-
-    kk = malloc(xsize * kmax * sizeof(float));
-    ...
-    xbounds = malloc(xsize * 2 * sizeof(int));
-
-``xsize`` is trusted user input. These multiplications can overflow,
-leading the ``malloc``'d buffer to be undersized. These allocations are
-followed by a loop that writes out of bounds. This can lead to
-corruption on the heap of the Python process with attacker controlled
-float data.
-
-This issue was found by Ned Williamson.