Chris Evans of the Google Security Team reports on his page a seemingly harmless
buffer overflow affecting bzip2:

  http://scary.beasts.org/security/CESA-2008-005.html

Rest is quoting Chris:

There exists a buffer overflow in decompress.c:

      GET_BITS(BZ_X_SELECTOR_2, nSelectors, 15);
      if (nSelectors < 1) RETURN(BZ_DATA_ERROR);
      for (i = 0; i < nSelectors; i++) {
         j = 0;
         while (True) {
            GET_BIT(BZ_X_SELECTOR_3, uc);
            if (uc == 0) break;
            j++;
            if (j >= nGroups) RETURN(BZ_DATA_ERROR);
         }
         s->selectorMtf[i] = j;
      }

The problem here is that nSelectors could be specified in a malicious archive as
up to 32767, but the selectorMtf array (and the selector array) only take 18002
entries.

This is probably harmless because the overflowed arrays are part of a struct
that looks like this:

      UChar    selector   [BZ_MAX_SELECTORS];
      UChar    selectorMtf[BZ_MAX_SELECTORS];
      UChar    len  [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];

      Int32    limit  [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];
      Int32    base   [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];
      Int32    perm   [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];
      Int32    minLens[BZ_N_GROUPS];

      /* save area for scalars in the main decompress code */
      Int32    save_i;
      Int32    save_j;

Those big arrays subsequent to selectorMtf are both big enough to absorb the 14k
or so of buffer overflow in its entirety, and are not referenced between the
time of the overflow and the time of initializing them. In addition, the
placement of "selector" before "selectorMtf" is fortunate because it means
unused selectorMtf values won't get corrupted as the selector values are stored.