[krbdev.mit.edu #3685] EOF mistakenly interpreted as error causes re-use of closed stream

[rainer.weikusat@sncag.com via RT]

Russ Allbery <rra at stanford.edu> writes:
> The RT System itself via RT <rt-comment at krbdev.mit.edu> writes:
>
>> 	The file mentioned in the subject contains the following code
>> 	section, which is supposed to deal with read errors occuring
>> 	during an attempted kvno read from an existing keytab file:
>
>>         if (!xfread(&kt_vno, sizeof(kt_vno), 1, KTFILEP(id))) {
>>             if (feof(KTFILEP(id))) kerror = KRB5_KT_END;
>>             else kerror = errno;
>             
>>             (void) krb5_unlock_file(context, fileno(KTFILEP(id)));
>>             (void) fclose(KTFILEP(id));
>>             return kerror;
>>         }
>
>> 	This is incorrect, because xfread (fread) can return zero if the
>> 	file exists and is empty, with errno also being zero (because no
>> 	error ocurred), which will lead to the stream being closed without
>> 	an error indication passed up to the caller (which, in my case,
>> 	will proceed with calling fseek on the closed stream, returning
>> 	KRB5_KT_END as EINVAL-in-disguise and finally crashing inside
>> 	malloc while trying to format an error message to be printed
>> 	describing this error (add codepath)).
>
> Yup, this is RT #3549, which I think includes a slightly better patch
> courtesy of Steve Langasek.

Presumably, because it returns a totally random synthetic system error
that bears absolutely no relation to the condition that caused it?
(keytab w/o kvno)

Do me a favor and *DO NOT* send me any of this "Hey, I know this guy
but who an earth are you"-nonsense again, ok?