Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docker checkpoint got "Unable to parse the CRIU version: Version: 1.5" #4

Closed
kimh opened this issue May 19, 2015 · 3 comments
Closed

docker checkpoint got "Unable to parse the CRIU version: Version: 1.5" #4

kimh opened this issue May 19, 2015 · 3 comments

Comments

@kimh
Copy link

kimh commented May 19, 2015

Now, I'm trying to use native docker checkpoint/resume. However, I got the following error when I run docker checkpoint $container_id.

root@vagrant-ubuntu-trusty:~/docker# ./bundles/1.5.0-dev/binary/docker checkpoint f82be2e71cd1
Error response from daemon: Cannot checkpoint container f82be2e71cd1: Unable to parse the CRIU version: Version: 1.5
GitID: v1.2-1326-ga8e1f59
FATA[0000] Error: failed to checkpoint one or more containers

Here is my environment.

Docker: compiled from https://github.com/boucher/docker/tree/boucher-cr
CRIU: avagin@9fc4975

Actually, I'm now sure how boucher's Docker and criu are related, but I installed criu under /usr/local/sbin/criu.

root@vagrant-ubuntu-trusty:~/docker# /usr/local/sbin/criu --version
Version: 1.5
GitID: v1.2-1326-ga8e1f59

Any ideas how to debug? Appriciate for your help.
@avagin
Copy link
Member

avagin commented May 19, 2015

It will be fixed automatically with the next release (1 Jun). Before this, you can fix the version in Makefile or build criu from the br-1.5-stable branch.

@avagin
Copy link
Member

avagin commented May 19, 2015

BTW: docker-archive/libcontainer#597

@kimh
Copy link
Author

kimh commented May 19, 2015

@avagin Cool, using br-1.5-stable works! Succeeded in checkpoint/redis container. I will close this the issue. Thank you for your help.

@kimh kimh closed this as completed May 19, 2015
xemul pushed a commit that referenced this issue Sep 10, 2015
@avagin @xemul
zdtm: use pthread_create to create a thread
a99d47e 
If you call clone directly you are responsible for setting up the TLS area yourself.

$ abrt-cli ls  | grep different_creds | wc -l
39
$ gdb -c /var/spool/abrt/ccpp-2015-07-24-10\:21\:14-8014/coredump  different_creds
 Core was generated by `./different_creds --pidfile=different_creds.pid --outfile=different_creds.out'.
 Program terminated with signal SIGILL, Illegal instruction.
 #0  0x00007f86e2d8c7d9 in _dl_x86_64_restore_sse () from /lib64/ld-linux-x86-64.so.2
 Missing separate debuginfos, use: dnf debuginfo-install glibc-2.21-7.fc22.x86_64 libattr-2.4.47-9.fc22.x86_64 libcap-2.24-7.fc22.x86_64
 (gdb) bt
 #0  0x00007f86e2d8c7d9 in _dl_x86_64_restore_sse () from /lib64/ld-linux-x86-64.so.2
 #1  0x00007f86e2d84add in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
 #2  0x00007f86e2d8bbc0 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
 #3  0x0000000000402da3 in sys_futex (val3=0, uaddr2=0x0, timeout=0x0, val=0, op=0, uaddr=0x6063f0 <sig_received>) at lock.h:29
 #4  futex_wait_while (f=0x6063f0 <sig_received>, v=0) at lock.h:121
 #5  test_waitsig () at test.c:367
 #6  0x0000000000401c4b in main (argc=<optimized out>, argv=0x7ffce16432f8) at different_creds.c:82

Reported-by: Mr Jenkins
Cc: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
xemul pushed a commit that referenced this issue Apr 12, 2016
@avagin @xemul
namespaces: don't leak memory on error paths
abcf3b2 
CID 159849 (#4 of 4): Resource leak (RESOURCE_LEAK)
15. leaked_storage: Variable jn going out of scope leaks the storage it points to.

Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
xemul pushed a commit that referenced this issue May 16, 2016
@avagin @xemul
namespaces: don't leak memory on error paths
89688a6 
CID 159849 (#4 of 4): Resource leak (RESOURCE_LEAK)
15. leaked_storage: Variable jn going out of scope leaks the storage it points to.

Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
@kikosha kikosha mentioned this issue May 29, 2016
Closed
xemul pushed a commit that referenced this issue Jun 1, 2016
@avagin @xemul
namespaces: don't leak memory on error paths
9f0ddf0 
CID 159849 (#4 of 4): Resource leak (RESOURCE_LEAK)
15. leaked_storage: Variable jn going out of scope leaks the storage it points to.

Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
criupatchwork pushed a commit to criupatchwork/criu that referenced this issue Jun 2, 2016
@avagin
zdtm/ptrace_sig: don't print from signal handlers
f56833c 
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
@avagin @xemul
zdtm/ptrace_sig: don't print from signal handlers
860dafd 
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
@avagin @xemul
zdtm/ptrace_sig: don't print from signal handlers
dcc26b2 
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
@avagin @xemul
zdtm/ptrace_sig: don't print from signal handlers
1cd1da9 
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
@avagin
sk-unix: set mntinfo
6dafefd 
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
@avagin
cr-check: fill up a root task mount namespace
d4443c0 
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
@avagin @xemul
cr-check: fill up a root task mount namespace
5988ec5 
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
@avagin @xemul
cr-check: fill up a root task mount namespace
4d5d46d 
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 xemul mentioned this issue Nov 16, 2016
Closed
@xemul xemul mentioned this issue Dec 5, 2016
Closed
0x7f454c46 pushed a commit to 0x7f454c46/criu that referenced this issue Jan 30, 2017
@avagin
zdtm/ptrace_sig: don't print from signal handlers
8135840 
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
@aryabinin @avagin
files-reg: fix use-after-free in open_remap_ghost()
0835e1d 
Ghost file entry used right after it has been freed:
	ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dc50
	READ of size 4 at 0x60700000dc50 thread T0
	    #0 0x46e819 in open_remap_ghost criu/files-reg.c:312
	    #1 0x46e819 in prepare_one_remap criu/files-reg.c:461
	    #2 0x46e819 in prepare_remaps criu/files-reg.c:507
	    checkpoint-restore#3 0x45af00 in root_prepare_shared criu/cr-restore.c:235
	    checkpoint-restore#4 0x45af00 in restore_task_with_children criu/cr-restore.c:1421
	    checkpoint-restore#5 0x7efc71e85f0c in clone (/lib64/libc.so.6+0xe7f0c)

	0x60700000dc50 is located 32 bytes inside of 80-byte region [0x60700000dc30,0x60700000dc80)
	freed by thread T0 here:
	    #0 0x7efc7305184a in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x9884a)
	    #1 0x46e4df in open_remap_ghost criu/files-reg.c:309
	    #2 0x46e4df in prepare_one_remap criu/files-reg.c:461
	    checkpoint-restore#3 0x46e4df in prepare_remaps criu/files-reg.c:507

	previously allocated by thread T0 here:
	    #0 0x7efc73051b82 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x98b82)
	    #1 0x7efc7277a8ea in protobuf_c_message_unpack (/usr/lib64/libprotobuf-c.so.1+0x48ea)
	    #2 0xd528232002838017  (<unknown module>)

Just move freeing after the last 'gfe' usage to fix this.

Fixes: d0097b2 ("files: Support ghost directories restore")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
criupatchwork pushed a commit to criupatchwork/criu that referenced this issue Jan 30, 2017
@aryabinin @avagin
net: fix stack out-of-bounds access in dump_one_netdev()
03229e1 
'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
@aryabinin @xemul
files-reg: fix use-after-free in open_remap_ghost()
8a106d8 
Ghost file entry used right after it has been freed:
	ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dc50
	READ of size 4 at 0x60700000dc50 thread T0
	    #0 0x46e819 in open_remap_ghost criu/files-reg.c:312
	    #1 0x46e819 in prepare_one_remap criu/files-reg.c:461
	    #2 0x46e819 in prepare_remaps criu/files-reg.c:507
	    #3 0x45af00 in root_prepare_shared criu/cr-restore.c:235
	    #4 0x45af00 in restore_task_with_children criu/cr-restore.c:1421
	    #5 0x7efc71e85f0c in clone (/lib64/libc.so.6+0xe7f0c)

	0x60700000dc50 is located 32 bytes inside of 80-byte region [0x60700000dc30,0x60700000dc80)
	freed by thread T0 here:
	    #0 0x7efc7305184a in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x9884a)
	    #1 0x46e4df in open_remap_ghost criu/files-reg.c:309
	    #2 0x46e4df in prepare_one_remap criu/files-reg.c:461
	    #3 0x46e4df in prepare_remaps criu/files-reg.c:507

	previously allocated by thread T0 here:
	    #0 0x7efc73051b82 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x98b82)
	    #1 0x7efc7277a8ea in protobuf_c_message_unpack (/usr/lib64/libprotobuf-c.so.1+0x48ea)
	    #2 0xd528232002838017  (<unknown module>)

Just move freeing after the last 'gfe' usage to fix this.

Fixes: d0097b2 ("files: Support ghost directories restore")
travis-ci: success for files-reg: fix use-after-free in open_remap_ghost()
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
xemul pushed a commit that referenced this issue Jan 31, 2017
@aryabinin @xemul
net: fix stack out-of-bounds access in dump_one_netdev()
607784c 
'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
@aryabinin @xemul
files-reg: fix use-after-free in open_remap_ghost()
12bce91 
Ghost file entry used right after it has been freed:
	ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dc50
	READ of size 4 at 0x60700000dc50 thread T0
	    #0 0x46e819 in open_remap_ghost criu/files-reg.c:312
	    #1 0x46e819 in prepare_one_remap criu/files-reg.c:461
	    #2 0x46e819 in prepare_remaps criu/files-reg.c:507
	    #3 0x45af00 in root_prepare_shared criu/cr-restore.c:235
	    #4 0x45af00 in restore_task_with_children criu/cr-restore.c:1421
	    #5 0x7efc71e85f0c in clone (/lib64/libc.so.6+0xe7f0c)

	0x60700000dc50 is located 32 bytes inside of 80-byte region [0x60700000dc30,0x60700000dc80)
	freed by thread T0 here:
	    #0 0x7efc7305184a in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x9884a)
	    #1 0x46e4df in open_remap_ghost criu/files-reg.c:309
	    #2 0x46e4df in prepare_one_remap criu/files-reg.c:461
	    #3 0x46e4df in prepare_remaps criu/files-reg.c:507

	previously allocated by thread T0 here:
	    #0 0x7efc73051b82 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x98b82)
	    #1 0x7efc7277a8ea in protobuf_c_message_unpack (/usr/lib64/libprotobuf-c.so.1+0x48ea)
	    #2 0xd528232002838017  (<unknown module>)

Just move freeing after the last 'gfe' usage to fix this.

Fixes: d0097b2 ("files: Support ghost directories restore")
travis-ci: success for files-reg: fix use-after-free in open_remap_ghost()
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
xemul pushed a commit that referenced this issue Feb 1, 2017
@aryabinin @xemul
net: fix stack out-of-bounds access in dump_one_netdev()
53d8e58 
'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
@aryabinin @xemul
files-reg: fix use-after-free in open_remap_ghost()
ec40484 
Ghost file entry used right after it has been freed:
	ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dc50
	READ of size 4 at 0x60700000dc50 thread T0
	    #0 0x46e819 in open_remap_ghost criu/files-reg.c:312
	    #1 0x46e819 in prepare_one_remap criu/files-reg.c:461
	    #2 0x46e819 in prepare_remaps criu/files-reg.c:507
	    #3 0x45af00 in root_prepare_shared criu/cr-restore.c:235
	    #4 0x45af00 in restore_task_with_children criu/cr-restore.c:1421
	    #5 0x7efc71e85f0c in clone (/lib64/libc.so.6+0xe7f0c)

	0x60700000dc50 is located 32 bytes inside of 80-byte region [0x60700000dc30,0x60700000dc80)
	freed by thread T0 here:
	    #0 0x7efc7305184a in __interceptor_free (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x9884a)
	    #1 0x46e4df in open_remap_ghost criu/files-reg.c:309
	    #2 0x46e4df in prepare_one_remap criu/files-reg.c:461
	    #3 0x46e4df in prepare_remaps criu/files-reg.c:507

	previously allocated by thread T0 here:
	    #0 0x7efc73051b82 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2+0x98b82)
	    #1 0x7efc7277a8ea in protobuf_c_message_unpack (/usr/lib64/libprotobuf-c.so.1+0x48ea)
	    #2 0xd528232002838017  (<unknown module>)

Just move freeing after the last 'gfe' usage to fix this.

Fixes: d0097b2 ("files: Support ghost directories restore")
travis-ci: success for files-reg: fix use-after-free in open_remap_ghost()
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
xemul pushed a commit that referenced this issue Feb 1, 2017
@aryabinin @xemul
net: fix stack out-of-bounds access in dump_one_netdev()
ea8483e 
'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
@avagin
unix: a unix name can be a non-null terminated string
a5473cb 
==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
@avagin
unix: a unix name can be a non-null terminated string
e763971 
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
@avagin
unix: a unix name can be a non-null terminated string
da8e89c 
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
@avagin
unix: a unix name can be a non-null terminated string
9b275ff 
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
@avagin
unix: a unix name can be a non-null terminated string
8abb4a7 
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
@avagin
unix: a unix name can be a non-null terminated string
848b165 
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>
criupatchwork pushed a commit to criupatchwork/criu that referenced this issue Sep 29, 2017
@avagin
zdtm/chroot: allocate enough memory for a path
e22b893 
==36==ERROR: AddressSanitizer: heap-buffer-overflow on address
	0x60200000001c at pc 0x7fb26c88d5f9 bp 0x7ffc15087d40 sp 0x7ffc150874d0
WRITE of size 13 at 0x60200000001c thread T0
    #0 0x7fb26c88d5f8 in vsprintf (/lib64/libasan.so.4+0x9e5f8)
    #1 0x7fb26c88d986 in __interceptor_sprintf (/lib64/libasan.so.4+0x9e986)
    #2 0x402453 in main /root/git/main/criu/test/zdtm/static/chroot.c:68
    checkpoint-restore#3 0x7fb26c43e4d9 in __libc_start_main (/lib64/libc.so.6+0x204d9)
    checkpoint-restore#4 0x4031b9 in _start (/root/git/main/criu/test/zdtm/static/chroot+0x4031b9)

Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
avagin added a commit that referenced this issue Sep 30, 2017
@avagin
zdtm/chroot: allocate enough memory for a path
aba5e69 
==36==ERROR: AddressSanitizer: heap-buffer-overflow on address
	0x60200000001c at pc 0x7fb26c88d5f9 bp 0x7ffc15087d40 sp 0x7ffc150874d0
WRITE of size 13 at 0x60200000001c thread T0
    #0 0x7fb26c88d5f8 in vsprintf (/lib64/libasan.so.4+0x9e5f8)
    #1 0x7fb26c88d986 in __interceptor_sprintf (/lib64/libasan.so.4+0x9e986)
    #2 0x402453 in main /root/git/main/criu/test/zdtm/static/chroot.c:68
    #3 0x7fb26c43e4d9 in __libc_start_main (/lib64/libc.so.6+0x204d9)
    #4 0x4031b9 in _start (/root/git/main/criu/test/zdtm/static/chroot+0x4031b9)

Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
xemul pushed a commit that referenced this issue Oct 17, 2017
@avagin
zdtm/chroot: allocate enough memory for a path
4776182 
==36==ERROR: AddressSanitizer: heap-buffer-overflow on address
	0x60200000001c at pc 0x7fb26c88d5f9 bp 0x7ffc15087d40 sp 0x7ffc150874d0
WRITE of size 13 at 0x60200000001c thread T0
    #0 0x7fb26c88d5f8 in vsprintf (/lib64/libasan.so.4+0x9e5f8)
    #1 0x7fb26c88d986 in __interceptor_sprintf (/lib64/libasan.so.4+0x9e986)
    #2 0x402453 in main /root/git/main/criu/test/zdtm/static/chroot.c:68
    #3 0x7fb26c43e4d9 in __libc_start_main (/lib64/libc.so.6+0x204d9)
    #4 0x4031b9 in _start (/root/git/main/criu/test/zdtm/static/chroot+0x4031b9)

Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
This was referenced Mar 17, 2021
Closed
Open
@throwbear throwbear mentioned this issue May 15, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kimh @avagin