For me, the C++ code in the description does not compile.
I used this:
"""
#include <fstream>
#include <cstring>
  
int main () {
  std::fstream s;
  s.open ("test.txt", std::ios_base::in | std::ios_base::out | std::ios_base::binary);
  
  char data[8 * 1024];
  memset(data, 'A', sizeof(data));
  s.write(data, sizeof(data));
  
  s.seekg(0);
  
  char buf[8 * 1024];
  memset(buf, 0, sizeof(buf));
  s.read(buf, sizeof(buf));

  // s.seekg(8 * 1024);
  char data2[8 * 1024];
  memset(data2, 'B', sizeof(data2));
  s.write(data2, sizeof(data2));
  
  s.close();
  
  return 0;
}
"""

When removing the comment from the second s.seekg(), then the code does no longer segfault.

An additional information:
Read a character less and it won't segfault.
s.read(buf, sizeof(buf)-1);

As far as I have researched about this, Bidirection file streams require setting the output position indicator for the write after a read to get the desired results.

(In reply to Jos Collin from comment #3)
> As far as I have researched about this, Bidirection file streams require
> setting the output position indicator for the write after a read to get the
> desired results.

That's correct. Mixing reads and writes without intervening seeks or flushes is undefined, which is why the fstream gets into a corrupt state.

I have a prototype patch that prevents the recursion, and should only affect behaviour in undefined cases like this. It won't make the program correct, but it will prevent the infinite recursion that overflows the stack.

(In reply to Jonathan Wakely from comment #13)
> I have a prototype patch that prevents the recursion, and should only affect
> behaviour in undefined cases like this. It won't make the program correct,
> but it will prevent the infinite recursion that overflows the stack.

From a user perspective, I think the most desirable behaviour would be to detect the situation already at compile time and bail out.  Not sure if that detection is possible (or allowed by conventions/standards).

(In reply to Christian Horn from comment #14)
> From a user perspective, I think the most desirable behaviour would be to
> detect the situation already at compile time and bail out.  Not sure if that
> detection is possible (or allowed by conventions/standards).

That's impossible.

Although the C++ standard says that the seeks are required for correct behaviour, changes were to GCC's fstream code several years ago to insert the seeks automatically as needed. Although relying on this isn't necessarily portable to other implementations, GCC tries to make it work. However, the customer's testcase hits an edge case where the automatic seeking isn't done correctly and leads to a crash.

This is now fixed in upstream GCC, in a way that makes the original testcase work as expected: no intervening seek is needed between the read and write.

While we believe we have the right fix for this problem, the affected code is complex and we believe the fix should receive further real world testing by way of upstream GCC, DTS releases and Y stream RHEL releases before we support it as a Z stream update.

Reproduced with gcc-4.8.5-28.el7_5.1, works OK with gcc-4.8.5-36.el7.
VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3016