summaryrefslogtreecommitdiffstats
path: root/libcxx/include
diff options
context:
space:
mode:
authorPetr Hosek <phosek@chromium.org>2019-07-22 19:54:34 +0000
committerPetr Hosek <phosek@chromium.org>2019-07-22 19:54:34 +0000
commit89385633ba1f6c6afbc304460d6385b05edb428d (patch)
tree289101b451a4bdb73c64f9b8545c651feadfef33 /libcxx/include
parent69ebb02001f57a561c072b14f79f7d61a9c68e13 (diff)
downloadbcm5719-llvm-89385633ba1f6c6afbc304460d6385b05edb428d.tar.gz
bcm5719-llvm-89385633ba1f6c6afbc304460d6385b05edb428d.zip
[libc++] Set __file_ to 0 in basic_filebuf::close() even if fclose fails
This issue was detected by ASan in one of our tests. This test manually invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero exit status, so __file_ wasn't set to 0. Later when basic_filebuf destructor ran, we would enter the if (__file_) block again leading to heap-use-after-free error. The POSIX specification for fclose says that independently of the return value, fclose closes the underlying file descriptor and any further access (including another call to fclose()) to the stream results in undefined behavior. This is exactly what happened in our test case. To avoid this issue, we have to always set __file_ to 0 independently of the fclose return value. Differential Revision: https://reviews.llvm.org/D64979 llvm-svn: 366730
Diffstat (limited to 'libcxx/include')
-rw-r--r--libcxx/include/fstream5
1 files changed, 2 insertions, 3 deletions
diff --git a/libcxx/include/fstream b/libcxx/include/fstream
index 60a05b0d4b9..7db9017aca9 100644
--- a/libcxx/include/fstream
+++ b/libcxx/include/fstream
@@ -697,10 +697,9 @@ basic_filebuf<_CharT, _Traits>::close()
unique_ptr<FILE, int(*)(FILE*)> __h(__file_, fclose);
if (sync())
__rt = 0;
- if (fclose(__h.release()) == 0)
- __file_ = 0;
- else
+ if (fclose(__h.release()))
__rt = 0;
+ __file_ = 0;
setbuf(0, 0);
}
return __rt;
OpenPOWER on IntegriCloud