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

The bug of the docker_cr.sh #7

Closed
YaoZengzeng opened this issue Jul 18, 2015 · 5 comments
Closed

The bug of the docker_cr.sh #7

YaoZengzeng opened this issue Jul 18, 2015 · 5 comments

Comments

@YaoZengzeng
Copy link

When I verify the external C/R with docker_cr.sh ,I can dump the container successfully.

root@iZu1pbgsilbZ:/home/monster# ./docker_cr.sh -c -v 61002d6899a8007ff82e72906cd658a78b427d3c078c1374359fd263f301697a
docker binary: docker
dockerinit binary: /var/lib/docker/init/dockerinit-1.7.0-dev
criu binary: criu
image directory: /var/lib/docker/criu_img/61002d6899a8007ff82e72906cd658a78b427d3c078c1374359fd263f301697a
container root directory: /var/lib/docker/aufs/mnt/61002d6899a8007ff82e72906cd658a78b427d3c078c1374359fd263f301697a

criu dump -v4 -D /var/lib/docker/criu_img/61002d6899a8007ff82e72906cd658a78b427d3c078c1374359fd263f301697a -o dump.log --manage-cgroups --evasive-devices --ext-mount-map /etc/resolv.conf:/etc/resolv.conf --ext-mount-map /etc/hosts:/etc/hosts --ext-mount-map /etc/hostname:/etc/hostname --ext-mount-map /.dockerinit:/.dockerinit -t 18622 --root /var/lib/docker/aufs/mnt/61002d6899a8007ff82e72906cd658a78b427d3c078c1374359fd263f301697a

dump successful
(00.026438) Dumping finished successfully

But when I want to restore the container,I meet the bug .

restore failed
(00.051080) 1: Error (rst-malloc.c:130): BUG at rst-malloc.c:130
(00.063390) Error (cr-restore.c:1221): 19157 killed by signal 11
(00.063482) Error (cr-restore.c:1912): Restoring FAILED.

I don't know why.Please help me .Thanks!
@YaoZengzeng
Copy link
Author

@xemul @SaiedKazemi @boucher Thanks

@boucher
Copy link

boucher commented Jul 18, 2015

I believe @xemul has a patch for this?

@xemul
Copy link
Member

xemul commented Jul 20, 2015

Yup, should be fixed by 7b20f42 commit.

@YaoZengzeng
Copy link
Author

@xemul Thanks .The problem has been solved.But criu seems not work well with docker 1.8.0.When I test checkpoint and restore,It will report bug.The details you can see in another issue.

@xemul
Copy link
Member

xemul commented Jul 20, 2015

OK, I'll close this bug then :) Thanks!

@xemul xemul closed this as completed Jul 20, 2015
avagin referenced this issue in avagin/criu Dec 4, 2015
@avagin
mount: don't rewrite root for external mounts
7fa58fb 
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
@kikosha kikosha mentioned this issue May 29, 2016
Closed
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
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
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
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
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>
@yinshuisiquan yinshuisiquan mentioned this issue Mar 17, 2021
Closed
@yinshuisiquan yinshuisiquan mentioned this issue Mar 17, 2021
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
3 participants
@boucher @xemul @YaoZengzeng