Attached is the MTR test that demonstrates the bug. Also a patch with a proposed fix.

The problem is that during ALTER TABLE IMPORT TABLESPACE two things happen:

• Regardless of whether the tablespace is encrypted, the current LSN (8 bytes) gets written at FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION
• Then if the page is encrypted the first 4 bytes at that offset are being interpreted as key_version while the remainder as the CRC32 checksum. If the key_version is non-zero, CRC32 check of the page is performed (fil0import.cc:3599) . So if the LSN >= 1 << 32 we perform the check, which will most likely fail as we are comparing the lowest 4 bytes of the LSN against the computed CRC-32 checksum of the page thus resulting in the error message to the client.

I believe the right thing to do is to not write the LSN at FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION for encrypted pages. At least it fixes the problem at hand.