After restoring a container with CRIU, a segfault consistently occurs in libz due to a corrupted pointer

This happens when checkpointing libz during the execution of a specific function.
With it always segfaulting in the exact same spot in that function after restoring (and unfreezing).

Libz is loaded in as a dynamic library.

This happens due to the value of a pointer located in memory changing between the CR.
When restoring it's always this specific pointer that gets altered.

As far as I can tell the rest of the memory is valid apart from this one value.

Another peculiarity is that regardless of the original value of the pointer, after restore it gets set to 0x15b75.

With the coredump utility in CRIU as well as manually looking at the page.img; I'm able to see that value in the checkpoint image is checkpointed is correct.
So it seems more so a problem when restoring.

While debugging the issue I've been restoring with --leave-stopped and then attatching to it using gdb.
With this I can see how immediately after restore that location of memory already has the value 0x15b75.

Because of this I feel confident that the issue is during the restore phase of CRIU.

I was wondering if anybody has any knowledge of something like this happening before?
Or if there are any recommendations on how to debug the alteration to the processes's memory?

Any debugging tips or directions to look further would be greatly appreciated!

The corresponding code where the program segfaults:
https://github.com/madler/zlib/blob/e8fee0ea7bf62e595bd5518b7b22e3e16397278c/deflate.c#L1259-L1264