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 <avagin@openvz.org> Signed-off-by: Andrew Vagin <avagin@virtuozzo.com> Tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
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 <avagin@openvz.org> Signed-off-by: Andrew Vagin <avagin@virtuozzo.com> Tested-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <avagin@openvz.org> Signed-off-by: Andrew Vagin <avagin@virtuozzo.com> Tested-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <avagin@openvz.org> Signed-off-by: Andrew Vagin <avagin@virtuozzo.com> Tested-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <christian.brauner@canonical.com>
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 <avagin@virtuozzo.com>
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 <avagin@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <avagin@virtuozzo.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <cov@codeaurora.org> Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by: Kir Kolyshkin <kir@openvz.org> Reviewed-by: Christopher Covington <cov@codeaurora.org>
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 <cov@codeaurora.org> Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by: Kir Kolyshkin <kir@openvz.org>
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 <cov@codeaurora.org> Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by: Kir Kolyshkin <kir@openvz.org> Reviewed-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <cov@codeaurora.org> Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by: Kir Kolyshkin <kir@openvz.org> Reviewed-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <avagin@openvz.org> Signed-off-by: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by: Cyrill Gorcunov <gorcunov@virtuozzo.com>
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 <aryabinin@virtuozzo.com>
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 <aryabinin@virtuozzo.com> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <aryabinin@virtuozzo.com> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <aryabinin@virtuozzo.com> Acked-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
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 <avagin@virtuozzo.com>
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 <avagin@virtuozzo.com>
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 <avagin@virtuozzo.com>
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 <avagin@virtuozzo.com>
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 <avagin@virtuozzo.com>
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 <avagin@virtuozzo.com>
This was referenced Mar 17, 2021
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: