Issue checkpointing larger container #8
Comments
|
Looks like enabling evasive-devices allows the checkpoint to finish successfully. |
avagin
referenced
this issue
in avagin/criu
Dec 4, 2015
It's used to restore bind-mounts. For example, we cat the common part of bind-mounts: Core was generated by `criu restore -vvvv --file-locks --tcp-established --evasive-devices --manage-cg'. Program terminated with signal 11, Segmentation fault. 741 BUG_ON(target_root[tok] == '\0'); (gdb) bt #0 0x000000000045eef2 in cut_root_for_bind (target_root=0x1e00f20 "/", source_root=0x1e04910 "/vzt/del/vzctl-rm-me.X99UVU8/.criu.cgyard.D5Dfcv/zdtmtst/") at mount.c:741 #1 0x000000000045f594 in do_bind_mount (mi=mi@entry=0x1e00dd0) at mount.c:2035 #2 0x000000000045fd02 in do_mount_one (mi=0x1e00dd0) at mount.c:2191 #3 0x000000000046241f in mnt_tree_for_each (fn=0x45fc80 <do_mount_one>, start=0x1e044d0) at mount.c:1759 #4 populate_mnt_ns () at mount.c:2729 #5 prepare_mnt_ns () at mount.c:2843 #6 0x000000000045a3c3 in prepare_namespace (item=0x7fe10b9ce050, clone_flags=2080505856) at namespaces.c:1311 #7 0x000000000043383e in restore_task_with_children (_arg=0x7ffd0f7faae0) at cr-restore.c:1535 #8 0x00007fe10acb41ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 https://jira.sw.ru/browse/PSBM-41932 Reported-by: Virtuozzo QA Team
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
Jun 2, 2016
It can be dead-lokced: #0 0x00007fafbf49f6ac in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007fafbf44af1c in _L_lock_2460 () from /lib64/libc.so.6 #2 0x00007fafbf44ad57 in __tz_convert () from /lib64/libc.so.6 checkpoint-restore#3 0x00000000004022e2 in test_msg (format=0x404508 "Receive signal %d\n") at msg.c:51 checkpoint-restore#4 <signal handler called> checkpoint-restore#5 0x00007fafbf3f2483 in __GI__IO_vfscanf () from /lib64/libc.so.6 checkpoint-restore#6 0x00007fafbf408f27 in vsscanf () from /lib64/libc.so.6 checkpoint-restore#7 0x00007fafbf4032f7 in sscanf () from /lib64/libc.so.6 checkpoint-restore#8 0x00007fafbf449ba6 in __tzset_parse_tz () from /lib64/libc.so.6 checkpoint-restore#9 0x00007fafbf44c4cb in __tzfile_compute () from /lib64/libc.so.6 checkpoint-restore#10 0x00007fafbf44ae17 in __tz_convert () from /lib64/libc.so.6 checkpoint-restore#11 0x00000000004022e2 in test_msg (format=format@entry=0x40458c "PASS\n") at msg.c:51 checkpoint-restore#12 0x0000000000401ceb in main (argc=<optimized out>, argv=<optimized out>) at ptrace_sig.c:172 https://jira.sw.ru/browse/PSBM-47772 Signed-off-by: Andrey Vagin <[email protected]> Signed-off-by: Andrew Vagin <[email protected]> Tested-by: Cyrill Gorcunov <[email protected]>
xemul
pushed a commit
that referenced
this issue
Jun 7, 2016
It can be dead-lokced: #0 0x00007fafbf49f6ac in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007fafbf44af1c in _L_lock_2460 () from /lib64/libc.so.6 #2 0x00007fafbf44ad57 in __tz_convert () from /lib64/libc.so.6 #3 0x00000000004022e2 in test_msg (format=0x404508 "Receive signal %d\n") at msg.c:51 #4 <signal handler called> #5 0x00007fafbf3f2483 in __GI__IO_vfscanf () from /lib64/libc.so.6 #6 0x00007fafbf408f27 in vsscanf () from /lib64/libc.so.6 #7 0x00007fafbf4032f7 in sscanf () from /lib64/libc.so.6 #8 0x00007fafbf449ba6 in __tzset_parse_tz () from /lib64/libc.so.6 #9 0x00007fafbf44c4cb in __tzfile_compute () from /lib64/libc.so.6 #10 0x00007fafbf44ae17 in __tz_convert () from /lib64/libc.so.6 #11 0x00000000004022e2 in test_msg (format=format@entry=0x40458c "PASS\n") at msg.c:51 #12 0x0000000000401ceb in main (argc=<optimized out>, argv=<optimized out>) at ptrace_sig.c:172 Signed-off-by: Andrey Vagin <[email protected]> Signed-off-by: Andrew Vagin <[email protected]> Tested-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
xemul
pushed a commit
that referenced
this issue
Jun 14, 2016
It can be dead-lokced: #0 0x00007fafbf49f6ac in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007fafbf44af1c in _L_lock_2460 () from /lib64/libc.so.6 #2 0x00007fafbf44ad57 in __tz_convert () from /lib64/libc.so.6 #3 0x00000000004022e2 in test_msg (format=0x404508 "Receive signal %d\n") at msg.c:51 #4 <signal handler called> #5 0x00007fafbf3f2483 in __GI__IO_vfscanf () from /lib64/libc.so.6 #6 0x00007fafbf408f27 in vsscanf () from /lib64/libc.so.6 #7 0x00007fafbf4032f7 in sscanf () from /lib64/libc.so.6 #8 0x00007fafbf449ba6 in __tzset_parse_tz () from /lib64/libc.so.6 #9 0x00007fafbf44c4cb in __tzfile_compute () from /lib64/libc.so.6 #10 0x00007fafbf44ae17 in __tz_convert () from /lib64/libc.so.6 #11 0x00000000004022e2 in test_msg (format=format@entry=0x40458c "PASS\n") at msg.c:51 #12 0x0000000000401ceb in main (argc=<optimized out>, argv=<optimized out>) at ptrace_sig.c:172 Signed-off-by: Andrey Vagin <[email protected]> Signed-off-by: Andrew Vagin <[email protected]> Tested-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
xemul
pushed a commit
that referenced
this issue
Jun 28, 2016
It can be dead-lokced: #0 0x00007fafbf49f6ac in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007fafbf44af1c in _L_lock_2460 () from /lib64/libc.so.6 #2 0x00007fafbf44ad57 in __tz_convert () from /lib64/libc.so.6 #3 0x00000000004022e2 in test_msg (format=0x404508 "Receive signal %d\n") at msg.c:51 #4 <signal handler called> #5 0x00007fafbf3f2483 in __GI__IO_vfscanf () from /lib64/libc.so.6 #6 0x00007fafbf408f27 in vsscanf () from /lib64/libc.so.6 #7 0x00007fafbf4032f7 in sscanf () from /lib64/libc.so.6 #8 0x00007fafbf449ba6 in __tzset_parse_tz () from /lib64/libc.so.6 #9 0x00007fafbf44c4cb in __tzfile_compute () from /lib64/libc.so.6 #10 0x00007fafbf44ae17 in __tz_convert () from /lib64/libc.so.6 #11 0x00000000004022e2 in test_msg (format=format@entry=0x40458c "PASS\n") at msg.c:51 #12 0x0000000000401ceb in main (argc=<optimized out>, argv=<optimized out>) at ptrace_sig.c:172 Signed-off-by: Andrey Vagin <[email protected]> Signed-off-by: Andrew Vagin <[email protected]> Tested-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
Sep 7, 2016
phys_stat_resolve() call mount_resolve_path() which requires that mntinfo_tree in the ns_id struct is initialized. This is a problem we observed with sockets on btrfs volumes: Program received signal SIGSEGV, Segmentation fault. 0x00005555555bb6dd in mount_resolve_path (mntinfo_tree=<optimized out>, path=0x555555875790 "/var/lib/lxd/unix.socket") at criu/mount.c:213 213 criu/mount.c: No such file or directory. (gdb) bt #0 0x00005555555bb6dd in mount_resolve_path (mntinfo_tree=<optimized out>, path=0x555555875790 "/var/lib/lxd/unix.socket") at criu/mount.c:213 #1 0x00005555555be240 in phys_stat_resolve_dev (ns=<optimized out>, st_dev=43, path=<optimized out>) at criu/mount.c:240 #2 0x00005555555be2bb in phys_stat_dev_match (st_dev=<optimized out>, phys_dev=41, ns=ns@entry=0x5555558753a0, path=path@entry=0x555555875790 "/var/lib/lxd/unix.socket") at criu/mount.c:256 checkpoint-restore#3 0x00005555555e75ed in unix_process_name (d=d@entry=0x5555558756e0, tb=tb@entry=0x7fffffffe0c0, m=<optimized out>) at criu/sk-unix.c:565 checkpoint-restore#4 0x00005555555e9378 in unix_collect_one (tb=0x7fffffffe0c0, m=0x555555869f18 <buf+312>) at criu/sk-unix.c:620 checkpoint-restore#5 unix_receive_one (h=0x555555869f08 <buf+296>, arg=<optimized out>) at criu/sk-unix.c:692 checkpoint-restore#6 0x00005555555b85aa in nlmsg_receive (buf=<optimized out>, arg=<optimized out>, err_cb=<optimized out>, cb=<optimized out>, len=<optimized out>) at criu/libnetlink.c:45 checkpoint-restore#7 do_rtnl_req (nl=nl@entry=5, req=req@entry=0x7fffffffe220, size=size@entry=72, receive_callback=0x5555555e9290 <unix_receive_one>, error_callback=0x5555555b83d0 <rtnl_return_err>, error_callback@entry=0x0, arg=arg@entry=0x0) at criu/libnetlink.c:119 checkpoint-restore#8 0x00005555555e9cf7 in do_collect_req (nl=nl@entry=5, req=req@entry=0x7fffffffe220, receive_callback=<optimized out>, arg=arg@entry=0x0, size=72) at criu/sockets.c:610 checkpoint-restore#9 0x00005555555eb1d0 in collect_sockets (ns=ns@entry=0x7fffffffe300) at criu/sockets.c:636 checkpoint-restore#10 0x000055555559ddfc in check_sock_diag () at criu/cr-check.c:118 checkpoint-restore#11 cr_check () at criu/cr-check.c:999 checkpoint-restore#12 0x00005555555872d0 in main (argc=<optimized out>, argv=0x7fffffffe678, envp=<optimized out>) at criu/crtools.c:719 Signed-off-by: Christian Brauner <[email protected]>
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
Oct 25, 2016
A root mount namespace list is used to resolve paths to unix sockets if they are placed on btrfs. This patch fixes a crash: #0 mount_resolve_path at criu/mount.c:213 #1 phys_stat_resolve_dev at criu/mount.c:240 #2 phys_stat_dev_match at criu/mount.c:256 checkpoint-restore#3 unix_process_name at criu/sk-unix.c:565 checkpoint-restore#4 unix_collect_one at criu/sk-unix.c:620 checkpoint-restore#5 unix_receive_one at criu/sk-unix.c:692 checkpoint-restore#6 nlmsg_receive at criu/libnetlink.c:45 checkpoint-restore#7 do_rtnl_req at criu/libnetlink.c:119 checkpoint-restore#8 do_collect_req at criu/sockets.c:610 checkpoint-restore#9 collect_sockets at criu/sockets.c:636 https://bugzilla.redhat.com/show_bug.cgi?id=1381351 Signed-off-by: Andrei Vagin <[email protected]>
xemul
pushed a commit
that referenced
this issue
Oct 26, 2016
A root mount namespace list is used to resolve paths to unix sockets if they are placed on btrfs. This patch fixes a crash: #0 mount_resolve_path at criu/mount.c:213 #1 phys_stat_resolve_dev at criu/mount.c:240 #2 phys_stat_dev_match at criu/mount.c:256 #3 unix_process_name at criu/sk-unix.c:565 #4 unix_collect_one at criu/sk-unix.c:620 #5 unix_receive_one at criu/sk-unix.c:692 #6 nlmsg_receive at criu/libnetlink.c:45 #7 do_rtnl_req at criu/libnetlink.c:119 #8 do_collect_req at criu/sockets.c:610 #9 collect_sockets at criu/sockets.c:636 travis-ci: success for cr-check: fill up a root task mount namespace https://bugzilla.redhat.com/show_bug.cgi?id=1381351 Signed-off-by: Andrei Vagin <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
xemul
pushed a commit
that referenced
this issue
Nov 2, 2016
A root mount namespace list is used to resolve paths to unix sockets if they are placed on btrfs. This patch fixes a crash: #0 mount_resolve_path at criu/mount.c:213 #1 phys_stat_resolve_dev at criu/mount.c:240 #2 phys_stat_dev_match at criu/mount.c:256 #3 unix_process_name at criu/sk-unix.c:565 #4 unix_collect_one at criu/sk-unix.c:620 #5 unix_receive_one at criu/sk-unix.c:692 #6 nlmsg_receive at criu/libnetlink.c:45 #7 do_rtnl_req at criu/libnetlink.c:119 #8 do_collect_req at criu/sockets.c:610 #9 collect_sockets at criu/sockets.c:636 travis-ci: success for cr-check: fill up a root task mount namespace https://bugzilla.redhat.com/show_bug.cgi?id=1381351 Signed-off-by: Andrei Vagin <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
Nov 4, 2016
I'm unsure where all these %%s before register names comes from, but they confuse clang, like this: > criu/arch/arm/parasite-head.S:6:6: error: unexpected token in operand > sub %r2, %pc, checkpoint-restore#8 @ get the address of this instruction > ^ This patch looks scary, but all it does is removing %s before register names, fixing a few "many spaces instead of a tab" issues along the way. Cc: Christopher Covington <[email protected]> Dmitry Safonov <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]> Reviewed-by: Christopher Covington <[email protected]>
kolyshkin
added a commit
to kolyshkin/criu
that referenced
this issue
Nov 4, 2016
I'm unsure where all these %%s before register names comes from, but they confuse clang, like this: > criu/arch/arm/parasite-head.S:6:6: error: unexpected token in operand > sub %r2, %pc, checkpoint-restore#8 @ get the address of this instruction > ^ This patch looks scary, but all it does is removing %s before register names, fixing a few "many spaces instead of a tab" issues along the way. Cc: Christopher Covington <[email protected]> Dmitry Safonov <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]>
xemul
pushed a commit
that referenced
this issue
Nov 4, 2016
I'm unsure where all these %%s before register names comes from, but they confuse clang, like this: > criu/arch/arm/parasite-head.S:6:6: error: unexpected token in operand > sub %r2, %pc, #8 @ get the address of this instruction > ^ This patch looks scary, but all it does is removing %s before register names, fixing a few "many spaces instead of a tab" issues along the way. travis-ci: success for Fixes to compile on arm with clang Cc: Christopher Covington <[email protected]> Dmitry Safonov <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]> Reviewed-by: Christopher Covington <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
xemul
pushed a commit
that referenced
this issue
Nov 12, 2016
I'm unsure where all these %%s before register names comes from, but they confuse clang, like this: > criu/arch/arm/parasite-head.S:6:6: error: unexpected token in operand > sub %r2, %pc, #8 @ get the address of this instruction > ^ This patch looks scary, but all it does is removing %s before register names, fixing a few "many spaces instead of a tab" issues along the way. travis-ci: success for Fixes to compile on arm with clang Cc: Christopher Covington <[email protected]> Dmitry Safonov <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]> Reviewed-by: Christopher Covington <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
0x7f454c46
pushed a commit
to 0x7f454c46/criu
that referenced
this issue
Jan 30, 2017
It can be dead-locked: #0 0x00007fafbf49f6ac in __lll_lock_wait_private () from /lib64/libc.so.6 checkpoint-restore#1 0x00007fafbf44af1c in _L_lock_2460 () from /lib64/libc.so.6 checkpoint-restore#2 0x00007fafbf44ad57 in __tz_convert () from /lib64/libc.so.6 checkpoint-restore#3 0x00000000004022e2 in test_msg (format=0x404508 "Receive signal %d\n") at msg.c:51 checkpoint-restore#4 <signal handler called> checkpoint-restore#5 0x00007fafbf3f2483 in __GI__IO_vfscanf () from /lib64/libc.so.6 checkpoint-restore#6 0x00007fafbf408f27 in vsscanf () from /lib64/libc.so.6 checkpoint-restore#7 0x00007fafbf4032f7 in sscanf () from /lib64/libc.so.6 checkpoint-restore#8 0x00007fafbf449ba6 in __tzset_parse_tz () from /lib64/libc.so.6 checkpoint-restore#9 0x00007fafbf44c4cb in __tzfile_compute () from /lib64/libc.so.6 checkpoint-restore#10 0x00007fafbf44ae17 in __tz_convert () from /lib64/libc.so.6 checkpoint-restore#11 0x00000000004022e2 in test_msg (format=format@entry=0x40458c "PASS\n") at msg.c:51 checkpoint-restore#12 0x0000000000401ceb in main (argc=<optimized out>, argv=<optimized out>) at ptrace_sig.c:172 https://jira.sw.ru/browse/PSBM-47772 Signed-off-by: Andrey Vagin <[email protected]> Signed-off-by: Andrew Vagin <[email protected]> Signed-off-by: Cyrill Gorcunov <[email protected]>
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
Jan 30, 2017
'info' array is off-by-one, nla_parse_nested() requires destination array (i.e. 'info') to have maxtype+1 (i.e. IFLA_INFO_MAX+1) elements: ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef823e3f8 WRITE of size 48 at 0x7ffef823e3f8 thread T0 #0 0x7f9ab7a3915b in __asan_memset (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x8d15b) #1 0x7f9ab6d4e553 in nla_parse (/usr/lib64/libnl-3.so.200+0xa553) #2 0x4acfb7 in dump_one_netdev criu/net.c:445 checkpoint-restore#3 0x4adb60 in dump_one_ethernet criu/net.c:594 checkpoint-restore#4 0x4adb60 in dump_one_link criu/net.c:665 checkpoint-restore#5 0x48af69 in nlmsg_receive criu/libnetlink.c:45 checkpoint-restore#6 0x48af69 in do_rtnl_req criu/libnetlink.c:119 checkpoint-restore#7 0x4b0e86 in dump_links criu/net.c:878 checkpoint-restore#8 0x4b0e86 in dump_net_ns criu/net.c:1651 checkpoint-restore#9 0x4a760d in do_dump_namespaces criu/namespaces.c:985 checkpoint-restore#10 0x4a760d in dump_namespaces criu/namespaces.c:1045 checkpoint-restore#11 0x451ef7 in cr_dump_tasks criu/cr-dump.c:1799 checkpoint-restore#12 0x424588 in main criu/crtools.c:736 checkpoint-restore#13 0x7f9ab67b171f in __libc_start_main (/lib64/libc.so.6+0x2071f) checkpoint-restore#14 0x4253d8 in _start (/criu/criu/criu+0x4253d8) Address 0x7ffef823e3f8 is located in stack of thread T0 at offset 264 in frame #0 0x4ac9ef in dump_one_netdev criu/net.c:364 This frame has 5 object(s): [32, 168) 'netdev' [224, 264) 'info' <== Memory access at offset 264 overflows this variable [320, 1040) 'req' [1088, 3368) 'path' [3424, 3625) 'stable_secret' Increase 'info' size to fix this. Fixes: b705dcc ("net: pass the struct nlattrs to dump() functions") Signed-off-by: Andrey Ryabinin <[email protected]>
xemul
pushed a commit
that referenced
this issue
Jan 31, 2017
'info' array is off-by-one, nla_parse_nested() requires destination array (i.e. 'info') to have maxtype+1 (i.e. IFLA_INFO_MAX+1) elements: ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef823e3f8 WRITE of size 48 at 0x7ffef823e3f8 thread T0 #0 0x7f9ab7a3915b in __asan_memset (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x8d15b) #1 0x7f9ab6d4e553 in nla_parse (/usr/lib64/libnl-3.so.200+0xa553) #2 0x4acfb7 in dump_one_netdev criu/net.c:445 #3 0x4adb60 in dump_one_ethernet criu/net.c:594 #4 0x4adb60 in dump_one_link criu/net.c:665 #5 0x48af69 in nlmsg_receive criu/libnetlink.c:45 #6 0x48af69 in do_rtnl_req criu/libnetlink.c:119 #7 0x4b0e86 in dump_links criu/net.c:878 #8 0x4b0e86 in dump_net_ns criu/net.c:1651 #9 0x4a760d in do_dump_namespaces criu/namespaces.c:985 #10 0x4a760d in dump_namespaces criu/namespaces.c:1045 #11 0x451ef7 in cr_dump_tasks criu/cr-dump.c:1799 #12 0x424588 in main criu/crtools.c:736 #13 0x7f9ab67b171f in __libc_start_main (/lib64/libc.so.6+0x2071f) #14 0x4253d8 in _start (/criu/criu/criu+0x4253d8) Address 0x7ffef823e3f8 is located in stack of thread T0 at offset 264 in frame #0 0x4ac9ef in dump_one_netdev criu/net.c:364 This frame has 5 object(s): [32, 168) 'netdev' [224, 264) 'info' <== Memory access at offset 264 overflows this variable [320, 1040) 'req' [1088, 3368) 'path' [3424, 3625) 'stable_secret' Increase 'info' size to fix this. Fixes: b705dcc ("net: pass the struct nlattrs to dump() functions") travis-ci: success for net: fix stack out-of-bounds access in dump_one_netdev() Signed-off-by: Andrey Ryabinin <[email protected]> Acked-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
xemul
pushed a commit
that referenced
this issue
Feb 1, 2017
'info' array is off-by-one, nla_parse_nested() requires destination array (i.e. 'info') to have maxtype+1 (i.e. IFLA_INFO_MAX+1) elements: ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef823e3f8 WRITE of size 48 at 0x7ffef823e3f8 thread T0 #0 0x7f9ab7a3915b in __asan_memset (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x8d15b) #1 0x7f9ab6d4e553 in nla_parse (/usr/lib64/libnl-3.so.200+0xa553) #2 0x4acfb7 in dump_one_netdev criu/net.c:445 #3 0x4adb60 in dump_one_ethernet criu/net.c:594 #4 0x4adb60 in dump_one_link criu/net.c:665 #5 0x48af69 in nlmsg_receive criu/libnetlink.c:45 #6 0x48af69 in do_rtnl_req criu/libnetlink.c:119 #7 0x4b0e86 in dump_links criu/net.c:878 #8 0x4b0e86 in dump_net_ns criu/net.c:1651 #9 0x4a760d in do_dump_namespaces criu/namespaces.c:985 #10 0x4a760d in dump_namespaces criu/namespaces.c:1045 #11 0x451ef7 in cr_dump_tasks criu/cr-dump.c:1799 #12 0x424588 in main criu/crtools.c:736 #13 0x7f9ab67b171f in __libc_start_main (/lib64/libc.so.6+0x2071f) #14 0x4253d8 in _start (/criu/criu/criu+0x4253d8) Address 0x7ffef823e3f8 is located in stack of thread T0 at offset 264 in frame #0 0x4ac9ef in dump_one_netdev criu/net.c:364 This frame has 5 object(s): [32, 168) 'netdev' [224, 264) 'info' <== Memory access at offset 264 overflows this variable [320, 1040) 'req' [1088, 3368) 'path' [3424, 3625) 'stable_secret' Increase 'info' size to fix this. Fixes: b705dcc ("net: pass the struct nlattrs to dump() functions") travis-ci: success for net: fix stack out-of-bounds access in dump_one_netdev() Signed-off-by: Andrey Ryabinin <[email protected]> Acked-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
xemul
pushed a commit
that referenced
this issue
Feb 1, 2017
'info' array is off-by-one, nla_parse_nested() requires destination array (i.e. 'info') to have maxtype+1 (i.e. IFLA_INFO_MAX+1) elements: ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef823e3f8 WRITE of size 48 at 0x7ffef823e3f8 thread T0 #0 0x7f9ab7a3915b in __asan_memset (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x8d15b) #1 0x7f9ab6d4e553 in nla_parse (/usr/lib64/libnl-3.so.200+0xa553) #2 0x4acfb7 in dump_one_netdev criu/net.c:445 #3 0x4adb60 in dump_one_ethernet criu/net.c:594 #4 0x4adb60 in dump_one_link criu/net.c:665 #5 0x48af69 in nlmsg_receive criu/libnetlink.c:45 #6 0x48af69 in do_rtnl_req criu/libnetlink.c:119 #7 0x4b0e86 in dump_links criu/net.c:878 #8 0x4b0e86 in dump_net_ns criu/net.c:1651 #9 0x4a760d in do_dump_namespaces criu/namespaces.c:985 #10 0x4a760d in dump_namespaces criu/namespaces.c:1045 #11 0x451ef7 in cr_dump_tasks criu/cr-dump.c:1799 #12 0x424588 in main criu/crtools.c:736 #13 0x7f9ab67b171f in __libc_start_main (/lib64/libc.so.6+0x2071f) #14 0x4253d8 in _start (/criu/criu/criu+0x4253d8) Address 0x7ffef823e3f8 is located in stack of thread T0 at offset 264 in frame #0 0x4ac9ef in dump_one_netdev criu/net.c:364 This frame has 5 object(s): [32, 168) 'netdev' [224, 264) 'info' <== Memory access at offset 264 overflows this variable [320, 1040) 'req' [1088, 3368) 'path' [3424, 3625) 'stable_secret' Increase 'info' size to fix this. Fixes: b705dcc ("net: pass the struct nlattrs to dump() functions") travis-ci: success for net: fix stack out-of-bounds access in dump_one_netdev() Signed-off-by: Andrey Ryabinin <[email protected]> Acked-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Pavel Emelyanov <[email protected]>
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
Mar 29, 2017
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298
READ of size 26 at 0x60300000e3ca thread T0
#0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0)
#1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d)
#2 0x4966cb in vprint_on_level criu/log.c:228
checkpoint-restore#3 0x496b64 in print_on_level criu/log.c:249
checkpoint-restore#4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401
checkpoint-restore#5 0x4e7ae3 in collect_image criu/protobuf.c:213
checkpoint-restore#6 0x462c5c in root_prepare_shared criu/cr-restore.c:247
checkpoint-restore#7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420
checkpoint-restore#8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec)
0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca)
allocated by thread T0 here:
#0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70)
#1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021)
Signed-off-by: Andrei Vagin <[email protected]>
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
Mar 30, 2017
In this patch, we replace all zero characters to '@'.
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298
READ of size 26 at 0x60300000e3ca thread T0
#0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0)
#1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d)
#2 0x4966cb in vprint_on_level criu/log.c:228
checkpoint-restore#3 0x496b64 in print_on_level criu/log.c:249
checkpoint-restore#4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401
checkpoint-restore#5 0x4e7ae3 in collect_image criu/protobuf.c:213
checkpoint-restore#6 0x462c5c in root_prepare_shared criu/cr-restore.c:247
checkpoint-restore#7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420
checkpoint-restore#8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec)
0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca)
allocated by thread T0 here:
#0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70)
#1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021)
Signed-off-by: Andrei Vagin <[email protected]>
avagin
added a commit
that referenced
this issue
Apr 5, 2017
In this patch, we replace all zero characters to '@'.
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298
READ of size 26 at 0x60300000e3ca thread T0
#0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0)
#1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d)
#2 0x4966cb in vprint_on_level criu/log.c:228
#3 0x496b64 in print_on_level criu/log.c:249
#4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401
#5 0x4e7ae3 in collect_image criu/protobuf.c:213
#6 0x462c5c in root_prepare_shared criu/cr-restore.c:247
#7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420
#8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec)
0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca)
allocated by thread T0 here:
#0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70)
#1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021)
Signed-off-by: Andrei Vagin <[email protected]>
avagin
added a commit
that referenced
this issue
Apr 5, 2017
In this patch, we replace all zero characters to '@'.
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298
READ of size 26 at 0x60300000e3ca thread T0
#0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0)
#1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d)
#2 0x4966cb in vprint_on_level criu/log.c:228
#3 0x496b64 in print_on_level criu/log.c:249
#4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401
#5 0x4e7ae3 in collect_image criu/protobuf.c:213
#6 0x462c5c in root_prepare_shared criu/cr-restore.c:247
#7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420
#8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec)
0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca)
allocated by thread T0 here:
#0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70)
#1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021)
Signed-off-by: Andrei Vagin <[email protected]>
xemul
pushed a commit
that referenced
this issue
Apr 12, 2017
In this patch, we replace all zero characters to '@'.
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298
READ of size 26 at 0x60300000e3ca thread T0
#0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0)
#1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d)
#2 0x4966cb in vprint_on_level criu/log.c:228
#3 0x496b64 in print_on_level criu/log.c:249
#4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401
#5 0x4e7ae3 in collect_image criu/protobuf.c:213
#6 0x462c5c in root_prepare_shared criu/cr-restore.c:247
#7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420
#8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec)
0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca)
allocated by thread T0 here:
#0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70)
#1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021)
Signed-off-by: Andrei Vagin <[email protected]>
0x7f454c46
pushed a commit
to 0x7f454c46/criu
that referenced
this issue
Jul 10, 2017
In this patch, we replace all zero characters to '@'.
==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298
READ of size 26 at 0x60300000e3ca thread T0
#0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0)
checkpoint-restore#1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d)
checkpoint-restore#2 0x4966cb in vprint_on_level criu/log.c:228
checkpoint-restore#3 0x496b64 in print_on_level criu/log.c:249
checkpoint-restore#4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401
checkpoint-restore#5 0x4e7ae3 in collect_image criu/protobuf.c:213
checkpoint-restore#6 0x462c5c in root_prepare_shared criu/cr-restore.c:247
checkpoint-restore#7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420
checkpoint-restore#8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec)
0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca)
allocated by thread T0 here:
#0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70)
checkpoint-restore#1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021)
Signed-off-by: Andrei Vagin <[email protected]>
This was referenced Mar 17, 2021
avagin
pushed a commit
that referenced
this issue
Jan 21, 2025
Running the zdtm/static/unlink_regular00 test on Ubuntu 24.04 on aarch64
results in following error:
# ./zdtm.py run -t zdtm/static/unlink_regular00 -k always
userns is supported
=== Run 1/1 ================ zdtm/static/unlink_regular00
==================== Run zdtm/static/unlink_regular00 in ns ====================
Skipping rtc at root
Start test
Test is SUID
./unlink_regular00 --pidfile=unlink_regular00.pid --outfile=unlink_regular00.out --dirname=unlink_regular00.test
Run criu dump
*** buffer overflow detected ***: terminated
############# Test zdtm/static/unlink_regular00 FAIL at CRIU dump ##############
Test output: ================================
<<< ================================
Send the 9 signal to 47
Wait for zdtm/static/unlink_regular00(47) to die for 0.100000
##################################### FAIL #####################################
According to the backtrace:
#0 __pthread_kill_implementation (threadid=281473158467616, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x0000ffff93477690 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x0000ffff9342cb3c in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x0000ffff93417e00 in __GI_abort () at ./stdlib/abort.c:79
#4 0x0000ffff9346abf0 in __libc_message_impl (fmt=fmt@entry=0xffff93552a78 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132
#5 0x0000ffff934e81a8 in __GI___fortify_fail (msg=msg@entry=0xffff93552a28 "buffer overflow detected") at ./debug/fortify_fail.c:24
#6 0x0000ffff934e79e4 in __GI___chk_fail () at ./debug/chk_fail.c:28
#7 0x0000ffff934e9070 in ___snprintf_chk (s=s@entry=0xffffc6ed04a3 "testfile", maxlen=maxlen@entry=4056, flag=flag@entry=2, slen=slen@entry=4053,
format=format@entry=0xaaaacffe3888 "link_remap.%d") at ./debug/snprintf_chk.c:29
#8 0x0000aaaacff4b8b8 in snprintf (__fmt=0xaaaacffe3888 "link_remap.%d", __n=4056, __s=0xffffc6ed04a3 "testfile")
at /usr/include/aarch64-linux-gnu/bits/stdio2.h:54
#9 create_link_remap (path=path@entry=0xffffc6ed2901 "/zdtm/static/unlink_regular00.test/subdir/testfile", len=len@entry=60, lfd=lfd@entry=20,
idp=idp@entry=0xffffc6ed14ec, nsid=nsid@entry=0xaaaada2bac00, parms=parms@entry=0xffffc6ed2808, fallback=0xaaaacff4c6c0 <dump_linked_remap+96>,
fallback@entry=0xffffc6ed2797) at criu/files-reg.c:1164
#10 0x0000aaaacff4c6c0 in dump_linked_remap (path=path@entry=0xffffc6ed2901 "/zdtm/static/unlink_regular00.test/subdir/testfile", len=len@entry=60,
parms=parms@entry=0xffffc6ed2808, lfd=lfd@entry=20, id=id@entry=12, nsid=nsid@entry=0xaaaada2bac00, fallback=fallback@entry=0xffffc6ed2797)
at criu/files-reg.c:1198
#11 0x0000aaaacff4d8b0 in check_path_remap (nsid=0xaaaada2bac00, id=12, lfd=20, parms=0xffffc6ed2808, link=<optimized out>) at criu/files-reg.c:1426
#12 dump_one_reg_file (lfd=20, id=12, p=0xffffc6ed2808) at criu/files-reg.c:1827
#13 0x0000aaaacff51078 in dump_one_file (pid=<optimized out>, fd=4, lfd=20, opts=opts@entry=0xaaaada2ba2c0, ctl=ctl@entry=0xaaaada2c4d50,
e=e@entry=0xffffc6ed39c8, dfds=dfds@entry=0xaaaada2c3d40) at criu/files.c:581
#14 0x0000aaaacff5176c in dump_task_files_seized (ctl=ctl@entry=0xaaaada2c4d50, item=item@entry=0xaaaada2b8f80, dfds=dfds@entry=0xaaaada2c3d40)
at criu/files.c:657
#15 0x0000aaaacff3d3c0 in dump_one_task (parent_ie=0x0, item=0xaaaada2b8f80) at criu/cr-dump.c:1679
#16 cr_dump_tasks (pid=<optimized out>) at criu/cr-dump.c:2224
#17 0x0000aaaacff163a0 in main (argc=<optimized out>, argv=0xffffc6ed40e8, envp=<optimized out>) at criu/crtools.c:293
This line is the problem:
snprintf(tmp + 1, sizeof(link_name) - (size_t)(tmp - link_name - 1), "link_remap.%d", rfe.id);
The problem was that the `-1` was on the inside of the braces and not on
the outside. This way the destination size was increase by 1 instead of
being decreased by 1 which triggered the buffer overflow detection.
Signed-off-by: Adrian Reber <[email protected]>
avagin
pushed a commit
that referenced
this issue
Mar 21, 2025
Running the zdtm/static/unlink_regular00 test on Ubuntu 24.04 on aarch64
results in following error:
# ./zdtm.py run -t zdtm/static/unlink_regular00 -k always
userns is supported
=== Run 1/1 ================ zdtm/static/unlink_regular00
==================== Run zdtm/static/unlink_regular00 in ns ====================
Skipping rtc at root
Start test
Test is SUID
./unlink_regular00 --pidfile=unlink_regular00.pid --outfile=unlink_regular00.out --dirname=unlink_regular00.test
Run criu dump
*** buffer overflow detected ***: terminated
############# Test zdtm/static/unlink_regular00 FAIL at CRIU dump ##############
Test output: ================================
<<< ================================
Send the 9 signal to 47
Wait for zdtm/static/unlink_regular00(47) to die for 0.100000
##################################### FAIL #####################################
According to the backtrace:
#0 __pthread_kill_implementation (threadid=281473158467616, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x0000ffff93477690 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x0000ffff9342cb3c in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x0000ffff93417e00 in __GI_abort () at ./stdlib/abort.c:79
#4 0x0000ffff9346abf0 in __libc_message_impl (fmt=fmt@entry=0xffff93552a78 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132
#5 0x0000ffff934e81a8 in __GI___fortify_fail (msg=msg@entry=0xffff93552a28 "buffer overflow detected") at ./debug/fortify_fail.c:24
#6 0x0000ffff934e79e4 in __GI___chk_fail () at ./debug/chk_fail.c:28
#7 0x0000ffff934e9070 in ___snprintf_chk (s=s@entry=0xffffc6ed04a3 "testfile", maxlen=maxlen@entry=4056, flag=flag@entry=2, slen=slen@entry=4053,
format=format@entry=0xaaaacffe3888 "link_remap.%d") at ./debug/snprintf_chk.c:29
#8 0x0000aaaacff4b8b8 in snprintf (__fmt=0xaaaacffe3888 "link_remap.%d", __n=4056, __s=0xffffc6ed04a3 "testfile")
at /usr/include/aarch64-linux-gnu/bits/stdio2.h:54
#9 create_link_remap (path=path@entry=0xffffc6ed2901 "/zdtm/static/unlink_regular00.test/subdir/testfile", len=len@entry=60, lfd=lfd@entry=20,
idp=idp@entry=0xffffc6ed14ec, nsid=nsid@entry=0xaaaada2bac00, parms=parms@entry=0xffffc6ed2808, fallback=0xaaaacff4c6c0 <dump_linked_remap+96>,
fallback@entry=0xffffc6ed2797) at criu/files-reg.c:1164
#10 0x0000aaaacff4c6c0 in dump_linked_remap (path=path@entry=0xffffc6ed2901 "/zdtm/static/unlink_regular00.test/subdir/testfile", len=len@entry=60,
parms=parms@entry=0xffffc6ed2808, lfd=lfd@entry=20, id=id@entry=12, nsid=nsid@entry=0xaaaada2bac00, fallback=fallback@entry=0xffffc6ed2797)
at criu/files-reg.c:1198
#11 0x0000aaaacff4d8b0 in check_path_remap (nsid=0xaaaada2bac00, id=12, lfd=20, parms=0xffffc6ed2808, link=<optimized out>) at criu/files-reg.c:1426
#12 dump_one_reg_file (lfd=20, id=12, p=0xffffc6ed2808) at criu/files-reg.c:1827
#13 0x0000aaaacff51078 in dump_one_file (pid=<optimized out>, fd=4, lfd=20, opts=opts@entry=0xaaaada2ba2c0, ctl=ctl@entry=0xaaaada2c4d50,
e=e@entry=0xffffc6ed39c8, dfds=dfds@entry=0xaaaada2c3d40) at criu/files.c:581
#14 0x0000aaaacff5176c in dump_task_files_seized (ctl=ctl@entry=0xaaaada2c4d50, item=item@entry=0xaaaada2b8f80, dfds=dfds@entry=0xaaaada2c3d40)
at criu/files.c:657
#15 0x0000aaaacff3d3c0 in dump_one_task (parent_ie=0x0, item=0xaaaada2b8f80) at criu/cr-dump.c:1679
#16 cr_dump_tasks (pid=<optimized out>) at criu/cr-dump.c:2224
#17 0x0000aaaacff163a0 in main (argc=<optimized out>, argv=0xffffc6ed40e8, envp=<optimized out>) at criu/crtools.c:293
This line is the problem:
snprintf(tmp + 1, sizeof(link_name) - (size_t)(tmp - link_name - 1), "link_remap.%d", rfe.id);
The problem was that the `-1` was on the inside of the braces and not on
the outside. This way the destination size was increase by 1 instead of
being decreased by 1 which triggered the buffer overflow detection.
Signed-off-by: Adrian Reber <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am getting the following error regarding cgroups states during checkpointing. I have tried all of the available modes in criu:
https://gist.github.com/stlalpha/f6121162d52bb0d423bf
The text was updated successfully, but these errors were encountered: