problems with corrupt (truncated) ccaches

Roland Dowdeswell elric at
Wed Nov 30 19:33:32 EST 2005

Was this ever resolved?  Looking at the 1.4.3 code, it looks like
this could still lead to a double free in the case of a truncated

On 1119456548 seconds since the Beginning of the UNIX epoch
Roland Dowdeswell wrote:
>I've noticed that if one's ccache is truncated in the wrong way
>that some applications will core dump on some OSes because of a
>double free.  (Of course a double free has undefined behaviour and
>hence a core dump conforms to the spec.)
>I attach a one line patch that removes the double free, but one is
>still left with a ccache to which additional tickets cannot be
>added.  Or at least, they are added but since they are simply
>appended they are in the wrong place.  In the best case they are
>ignored but I am convinced that there will be degenerate cases
>where e.g. malloc() will be called with ridiculous arguments, etc.
>I think that the code which adds tickets to ccaches should not
>simply append the tickets but rather find the offset of the last
>valid ticket seek() to it, ftruncate() the file and then append
>the ticket.
>Now, as for how we ended up with a truncated ccache---I don't know,
>but a process was probably killed at an inappropriate time or some
>    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/
>sasas1 $ cvs diff -ur1.1 -r1.2 cc_file.c
>Index: cc_file.c
>RCS file: /ms/dev/kerberos/mitkrb5/cvs-dirs/mitkrb5-1.4/mitkrb5/src/lib/krb5/c
>retrieving revision 1.1
>retrieving revision 1.2
>diff -u -u -r1.1 -r1.2
>--- cc_file.c   28 Mar 2005 21:43:34 -0000      1.1
>+++ cc_file.c   21 Jun 2005 19:00:13 -0000      1.2
>@@ -636,6 +636,7 @@
>  errout:
>      if (data->data)
> 	 krb5_xfree(data->data);
>+     data->data = NULL;
>      return kret;
> }       
>krbdev mailing list             krbdev at

    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

More information about the krbdev mailing list