[CRIU] Report corrupted remap if mapping table is too long

[Pavel Emelyanov]

On 06/05/2013 09:59 AM, Chanho Park wrote:
> Hi all,
> 
> I found self_vmas table of sigreturn_restore function was corrupted when
> smaps info is too long.
> Please see below restoration log:
> 
> (02.323645)  14094: parse_smaps: vma_area:0x174708 size:0x70
> (02.323668)  14094: parse_smaps: vma_area:0x174780 size:0x70
> (02.323690)  14094: parse_smaps: vma_area:0x1747f8 size:0x70
> (02.323726)  14094: parse_smaps: vma_area:0x174870 size:0x70
> (02.323807)  14094: 10 threads require 648K of memory
> (02.323962)  14094: Found bootstrap VMA hint at: 0x15b000 (needs ~912K)
> pie: Task 14094  exited, status= 11
> (05.391927) Error (cr-restore.c:1321): Restoring FAILED.
> 
> I inserted temporary log to print the address of each vma_area in the
> parse_smaps.
> In case the mapping table of the process is too long,
> it is corrupted after remap_restorer_blob because it is overlapped with
> exec_mem_hint address.
> For addressing the problem, I temporary moved the address of exec_mem_hint
> to avoid overlapped region.

It looks like the bug is in here -- the exec_mem_hint must give us an region
that doesn't intersect with both -- current task's (crtools's) mappings and
the target task's mappings (those read from image files). If for any reason
while filling this region we currupt memory in crtools, then the exec_mem_hint
routine is buggy.

> After that, the mapping information was changed compared with original
> mapping.
> 
> How do I address this issue gracefully?
> Thanks.
> 
> Best regards,
> Chanho Park
> 
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>