[exim-dev] [Bug 1835] Use after free of FILE *smtp_in, *smt…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: admin
Datum:  
To: exim-dev
Alte Treads: [exim-dev] [Bug 1835] New: Use after free of FILE *smtp_in, *smtp_out in server process after failed GnuTLS STARTTLS
Betreff: [exim-dev] [Bug 1835] Use after free of FILE *smtp_in, *smtp_out in server process after failed GnuTLS STARTTLS
https://bugs.exim.org/show_bug.cgi?id=1835

--- Comment #5 from Simon Arlott <bugzilla.exim.simon@???> ---
The comment is from the original import in 2004 and doesn't explain how to
produce the issue described so it's impossible to verify. Both GnuTLS and
OpenSSL will have changed significantly since then.

EBADF is a valid error code for fflush() because the fd located in the FILE
struct may have been closed, or it may be opened read only.


It is not valid to call any functions on FILE* that has been fclose()'d.

"In either case any further access (including another call to fclose()) to the
stream results in undefined behavior."


fclose() is the only way to release the FILE struct memory allocated by
fopen(). Further accesses will be using freed memory. There is no way for glibc
to know the difference between "FILE* that you want to keep using with
fflush()" and "FILE* that you're finished with" and there's no ffree(). Support
for the behaviour you're suggesting would cause a memory leak.

You're not seeing a crash because you need to experience the free'd memory
being overwritten in a suitable way to cause fflush() to crash. I have no way
to reproduce this on demand but exim regularly crashes in fflush() for me.

2016-09-21T17:08:25.730+01:00 <info> kernel: exim4[8640]: segfault at 8 ip
00007f1ba0a04776 sp 00007ffe17e91780 error 4 in
libc-2.23.so[7f1ba0997000+1c0000]

--
You are receiving this mail because:
You are on the CC list for the bug.