JehanneOS
/
newlib
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
newlib/winsup/cygwin/release/2.11.2

25 lines
650 B
Groff
Raw Normal View History

Cygwin: lseek: return ESPIPE rather than EINVAL when called on a fifo Thanks to Henri for tracking this down: https://cygwin.com/ml/cygwin/2018-10/msg00062.html Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2018-10-10 13:20:04 +02:00
What's new:
-----------
What changed:
-------------
Bug Fixes
---------
- Return ESPIPE rather than EINVAL from lseek on a fifo.
Addresses: https://cygwin.com/ml/cygwin/2018-10/msg00019.html
Cygwin: Fix cygheap corruption caused by cloned atomic buffer The fhandler_base_overlapped::copyto clears atomic_write_buf on the clone, but none of the derived classes were doing this. This allowed the destructor to double-free the buffer and corrupt cygheap. Clear atomic_write_buf in copyto of all derived classes.
2018-10-28 20:22:44 +01:00
- Fix a memory corruption when using pipes or FIFOs
Addresses: https://cygwin.com/ml/cygwin-patches/2018-q4/msg00000.html
Cygwin: fix memory corruption/SEGV if certain socket functions fail Regression introduced with 2.11.0: The failure paths in socket, socketpair and accept4 functions and methods accidentally release *unused* cygheap_fdmanip objects. The subsequently called dtable::release method was designed to be called for *used* cygheap_fdmanip objects only. Using them on unused objects leads to NULL pointer member dereferencing. Worse, the inet/local accept4 methods only release the cygheap_fdmanip object but neglect to delete the just created fhandler_socket_* object. Fix this by removing the erroneous release calls in the aforementioned failure paths and delete the fhandler_socket_* object in accept4 instead. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2018-10-29 16:12:54 +01:00
- Fix potential memory corruption and SEGV if socket(2), socketpair(2),
accept(2), or accept4(2) fail.
Addresses: https://cygwin.com/ml/cygwin/2018-10/msg00229.html
Cygwin: honor SOCK_NONBLOCK/SOCK_CLOEXEC in socket(2)/socketpair(2) fhandler_socket_wsock::set_socket_handle calls set_flags after setting the O_NONBLOCK/O_CLOEXEC flags, thus overwriting them. It also turns out that fhandler_socket_wsock::init_events is called too late. The inheritence flags are changed before creating the socket event handling objects. Thus, inheritence flags for those objects are wrong with SOCK_CLOEXEC. Fix this by reordering the calls and setting the file flags through fhandler_base::set_flags. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2018-11-05 21:02:22 +01:00
- Fix socket(2) and socketpair(2) calls mishandling SOCK_NONBLOCK and
SOCK_CLOEXEC flags.
Addresses: https://cygwin.com/ml/cygwin/2018-11/msg00017.html