lxc-archlinux outdated #11
Comments
|
Those initscripts parts are already removed in staging branch. The "base" group contains packages like "linux" that are not really required for container to work, but increase both installation time and space requirements notably. |
|
By the way, you can specify "base" group in additional packages template option like this: |
|
Sounds like this can be closed. |
stgraber
pushed a commit
to stgraber/lxc
that referenced
this issue
Dec 19, 2013
…orage (v2) While testing lxc#106, I found that concurrent starts are hanging time to time. I then reproduced the same problem in master and got following; [caglar@oOo:~] sudo gdb -p 16221 (gdb) bt #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007f495526515c in _L_lock_982 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f4955264fab in __GI___pthread_mutex_lock (mutex=0x7f49556d4600 <static_mutex>) at pthread_mutex_lock.c:64 #3 0x00007f49554b27a6 in lock_mutex (l=l@entry=0x7f49556d4600 <static_mutex>) at lxclock.c:78 #4 0x00007f49554b2dac in static_lock () at lxclock.c:330 #5 0x00007f4955498f71 in lxc_global_config_value (option_name=option_name@entry=0x7f49554c02cf "cgroup.use") at utils.c:273 #6 0x00007f495549926c in default_cgroup_use () at utils.c:366 lxc#7 0x00007f49554953bd in lxc_cgroup_load_meta () at cgroup.c:94 lxc#8 0x00007f495548debc in lxc_spawn (handler=handler@entry=0x7f49200af300) at start.c:783 lxc#9 0x00007f495548e7a7 in __lxc_start (name=name@entry=0x7f49200b48a0 "lxc-test-concurrent-4", conf=conf@entry=0x7f49200b2030, ops=ops@entry=0x7f49556d3900 <start_ops>, data=data@entry=0x7f495487db90, lxcpath=lxcpath@entry=0x7f49200b2010 "/var/lib/lxc") at start.c:951 lxc#10 0x00007f495548eb9c in lxc_start (name=0x7f49200b48a0 "lxc-test-concurrent-4", argv=argv@entry=0x7f495487dbe0, conf=conf@entry=0x7f49200b2030, lxcpath=0x7f49200b2010 "/var/lib/lxc") at start.c:1048 lxc#11 0x00007f49554b68f1 in lxcapi_start (c=0x7f49200b1dd0, useinit=<optimized out>, argv=0x7f495487dbe0) at lxccontainer.c:648 lxc#12 0x0000000000401317 in do_function (arguments=0x1aa80b0) at concurrent.c:94 lxc#13 0x0000000000401499 in concurrent (arguments=<optimized out>) at concurrent.c:130 lxc#14 0x00007f4955262f6e in start_thread (arg=0x7f495487e700) at pthread_create.c:311 lxc#15 0x00007f4954f8d9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 It looks like both parent and child end up with locked mutex thus deadlocks. I ended up placing values in the thread local storage pool, instead of doing "unlock the lock in the child" dance Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
stgraber
pushed a commit
that referenced
this issue
Dec 19, 2013
…orage (v2) While testing #106, I found that concurrent starts are hanging time to time. I then reproduced the same problem in master and got following; [caglar@oOo:~] sudo gdb -p 16221 (gdb) bt #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007f495526515c in _L_lock_982 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f4955264fab in __GI___pthread_mutex_lock (mutex=0x7f49556d4600 <static_mutex>) at pthread_mutex_lock.c:64 #3 0x00007f49554b27a6 in lock_mutex (l=l@entry=0x7f49556d4600 <static_mutex>) at lxclock.c:78 #4 0x00007f49554b2dac in static_lock () at lxclock.c:330 #5 0x00007f4955498f71 in lxc_global_config_value (option_name=option_name@entry=0x7f49554c02cf "cgroup.use") at utils.c:273 #6 0x00007f495549926c in default_cgroup_use () at utils.c:366 #7 0x00007f49554953bd in lxc_cgroup_load_meta () at cgroup.c:94 #8 0x00007f495548debc in lxc_spawn (handler=handler@entry=0x7f49200af300) at start.c:783 #9 0x00007f495548e7a7 in __lxc_start (name=name@entry=0x7f49200b48a0 "lxc-test-concurrent-4", conf=conf@entry=0x7f49200b2030, ops=ops@entry=0x7f49556d3900 <start_ops>, data=data@entry=0x7f495487db90, lxcpath=lxcpath@entry=0x7f49200b2010 "/var/lib/lxc") at start.c:951 #10 0x00007f495548eb9c in lxc_start (name=0x7f49200b48a0 "lxc-test-concurrent-4", argv=argv@entry=0x7f495487dbe0, conf=conf@entry=0x7f49200b2030, lxcpath=0x7f49200b2010 "/var/lib/lxc") at start.c:1048 #11 0x00007f49554b68f1 in lxcapi_start (c=0x7f49200b1dd0, useinit=<optimized out>, argv=0x7f495487dbe0) at lxccontainer.c:648 #12 0x0000000000401317 in do_function (arguments=0x1aa80b0) at concurrent.c:94 #13 0x0000000000401499 in concurrent (arguments=<optimized out>) at concurrent.c:130 #14 0x00007f4955262f6e in start_thread (arg=0x7f495487e700) at pthread_create.c:311 #15 0x00007f4954f8d9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 It looks like both parent and child end up with locked mutex thus deadlocks. I ended up placing values in the thread local storage pool, instead of doing "unlock the lock in the child" dance Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
hallyn
added a commit
to hallyn/lxc
that referenced
this issue
Nov 12, 2014
Convert CONTRIBUTING to markdown and some updates
z-image
pushed a commit
to z-image/lxc
that referenced
this issue
Oct 16, 2016
…orage (v2) While testing lxc#106, I found that concurrent starts are hanging time to time. I then reproduced the same problem in master and got following; [caglar@oOo:~] sudo gdb -p 16221 (gdb) bt #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 lxc#1 0x00007f495526515c in _L_lock_982 () from /lib/x86_64-linux-gnu/libpthread.so.0 lxc#2 0x00007f4955264fab in __GI___pthread_mutex_lock (mutex=0x7f49556d4600 <static_mutex>) at pthread_mutex_lock.c:64 lxc#3 0x00007f49554b27a6 in lock_mutex (l=l@entry=0x7f49556d4600 <static_mutex>) at lxclock.c:78 lxc#4 0x00007f49554b2dac in static_lock () at lxclock.c:330 lxc#5 0x00007f4955498f71 in lxc_global_config_value (option_name=option_name@entry=0x7f49554c02cf "cgroup.use") at utils.c:273 lxc#6 0x00007f495549926c in default_cgroup_use () at utils.c:366 lxc#7 0x00007f49554953bd in lxc_cgroup_load_meta () at cgroup.c:94 lxc#8 0x00007f495548debc in lxc_spawn (handler=handler@entry=0x7f49200af300) at start.c:783 lxc#9 0x00007f495548e7a7 in __lxc_start (name=name@entry=0x7f49200b48a0 "lxc-test-concurrent-4", conf=conf@entry=0x7f49200b2030, ops=ops@entry=0x7f49556d3900 <start_ops>, data=data@entry=0x7f495487db90, lxcpath=lxcpath@entry=0x7f49200b2010 "/var/lib/lxc") at start.c:951 lxc#10 0x00007f495548eb9c in lxc_start (name=0x7f49200b48a0 "lxc-test-concurrent-4", argv=argv@entry=0x7f495487dbe0, conf=conf@entry=0x7f49200b2030, lxcpath=0x7f49200b2010 "/var/lib/lxc") at start.c:1048 lxc#11 0x00007f49554b68f1 in lxcapi_start (c=0x7f49200b1dd0, useinit=<optimized out>, argv=0x7f495487dbe0) at lxccontainer.c:648 lxc#12 0x0000000000401317 in do_function (arguments=0x1aa80b0) at concurrent.c:94 lxc#13 0x0000000000401499 in concurrent (arguments=<optimized out>) at concurrent.c:130 lxc#14 0x00007f4955262f6e in start_thread (arg=0x7f495487e700) at pthread_create.c:311 lxc#15 0x00007f4954f8d9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 It looks like both parent and child end up with locked mutex thus deadlocks. I ended up placing values in the thread local storage pool, instead of doing "unlock the lock in the child" dance Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Closed
brauner
pushed a commit
to brauner/lxc
that referenced
this issue
Mar 27, 2021
It was found by ClusterFuzz in https://oss-fuzz.com/testcase-detail/4747480244813824 but hasn't been reported on Monorail (https://bugs.chromium.org/p/oss-fuzz/) yet ``` $ cat minimized-from-1a18983c13ce64e8a3bd0f699a97d25beb21481e lxc.net.0.hwaddr=0 lxc.net.0.hwaddr=4 ./out/fuzz-lxc-config-read minimized-from-1a18983c13ce64e8a3bd0f699a97d25beb21481e INFO: Seed: 1473396311 INFO: Loaded 1 modules (18821 inline 8-bit counters): 18821 [0x885fa0, 0x88a925), INFO: Loaded 1 PC tables (18821 PCs): 18821 [0x88a928,0x8d4178), ./out/fuzz-lxc-config-read: Running 1 inputs 1 time(s) each. Running: minimized-from-1a18983c13ce64e8a3bd0f699a97d25beb21481e ================================================================= ==226185==ERROR: LeakSanitizer: detected memory leaks Direct leak of 2 byte(s) in 1 object(s) allocated from: #0 0x4d25d7 in strdup (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x4d25d7) #1 0x58e48f in set_config_net_hwaddr /home/vagrant/lxc/src/lxc/confile.c:654:14 #2 0x59af3b in set_config_net_nic /home/vagrant/lxc/src/lxc/confile.c:5276:9 #3 0x571c29 in parse_line /home/vagrant/lxc/src/lxc/confile.c:2958:9 #4 0x61b0b2 in lxc_file_for_each_line_mmap /home/vagrant/lxc/src/lxc/parse.c:125:9 #5 0x5710ed in lxc_config_read /home/vagrant/lxc/src/lxc/confile.c:3035:9 #6 0x542cd6 in LLVMFuzzerTestOneInput /home/vagrant/lxc/src/tests/fuzz-lxc-config-read.c:23:2 lxc#7 0x449e8c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x449e8c) lxc#8 0x42bbad in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x42bbad) lxc#9 0x432c50 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x432c50) lxc#10 0x423136 in main (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x423136) lxc#11 0x7f2cbb992081 in __libc_start_main (/lib64/libc.so.6+0x27081) SUMMARY: AddressSanitizer: 2 byte(s) leaked in 1 allocation(s). ``` Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
brauner
pushed a commit
that referenced
this issue
Mar 29, 2021
It was triggered by passing "lxc.selinux.context.keyring=xroot" to the fuzz target introduced in google/oss-fuzz#5498 ``` ================================================================= ==22==ERROR: LeakSanitizer: detected memory leaks Direct leak of 6 byte(s) in 1 object(s) allocated from: #0 0x538ca4 in __strdup /src/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:468:3 #1 0x5c40e8 in set_config_string_item /src/lxc/src/lxc/confile_utils.c:635:14 #2 0x44394e in set_config_selinux_context_keyring /src/lxc/src/lxc/confile.c:1596:9 #3 0x5af955 in parse_line /src/lxc/src/lxc/confile.c:2953:9 #4 0x4475cd in lxc_file_for_each_line_mmap /src/lxc/src/lxc/parse.c:125:9 #5 0x5af24f in lxc_config_read /src/lxc/src/lxc/confile.c:3024:9 #6 0x580b04 in LLVMFuzzerTestOneInput /src/fuzz-lxc-config-read.c:36:2 #7 0x483643 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:599:15 #8 0x46d4a2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6 #9 0x4732ea in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:856:9 #10 0x49f022 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 #11 0x7f16d09b883f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) ``` This is a follow-up to 4fef78bc332a2d186dca6f Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
brauner
pushed a commit
that referenced
this issue
Mar 29, 2021
It was found by ClusterFuzz in https://oss-fuzz.com/testcase-detail/4747480244813824 but hasn't been reported on Monorail (https://bugs.chromium.org/p/oss-fuzz/) yet ``` $ cat minimized-from-1a18983c13ce64e8a3bd0f699a97d25beb21481e lxc.net.0.hwaddr=0 lxc.net.0.hwaddr=4 ./out/fuzz-lxc-config-read minimized-from-1a18983c13ce64e8a3bd0f699a97d25beb21481e INFO: Seed: 1473396311 INFO: Loaded 1 modules (18821 inline 8-bit counters): 18821 [0x885fa0, 0x88a925), INFO: Loaded 1 PC tables (18821 PCs): 18821 [0x88a928,0x8d4178), ./out/fuzz-lxc-config-read: Running 1 inputs 1 time(s) each. Running: minimized-from-1a18983c13ce64e8a3bd0f699a97d25beb21481e ================================================================= ==226185==ERROR: LeakSanitizer: detected memory leaks Direct leak of 2 byte(s) in 1 object(s) allocated from: #0 0x4d25d7 in strdup (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x4d25d7) #1 0x58e48f in set_config_net_hwaddr /home/vagrant/lxc/src/lxc/confile.c:654:14 #2 0x59af3b in set_config_net_nic /home/vagrant/lxc/src/lxc/confile.c:5276:9 #3 0x571c29 in parse_line /home/vagrant/lxc/src/lxc/confile.c:2958:9 #4 0x61b0b2 in lxc_file_for_each_line_mmap /home/vagrant/lxc/src/lxc/parse.c:125:9 #5 0x5710ed in lxc_config_read /home/vagrant/lxc/src/lxc/confile.c:3035:9 #6 0x542cd6 in LLVMFuzzerTestOneInput /home/vagrant/lxc/src/tests/fuzz-lxc-config-read.c:23:2 #7 0x449e8c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x449e8c) #8 0x42bbad in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x42bbad) #9 0x432c50 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x432c50) #10 0x423136 in main (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x423136) #11 0x7f2cbb992081 in __libc_start_main (/lib64/libc.so.6+0x27081) SUMMARY: AddressSanitizer: 2 byte(s) leaked in 1 allocation(s). ``` Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
brauner
pushed a commit
that referenced
this issue
Mar 29, 2021
MSan doesn't instrument stpncpy (google/sanitizers#926), which causes the fuzzer to fail with: ``` $ cat ../minimized-from-740f56329efc60eab59b8194132b712a873e88a3 lxc.console.size=123 $ ./out/fuzz-lxc-config-read ../minimized-from-740f56329efc60eab59b8194132b712a873e88a3 INFO: Seed: 3561494591 INFO: Loaded 1 modules (18795 inline 8-bit counters): 18795 [0x866b98, 0x86b503), INFO: Loaded 1 PC tables (18795 PCs): 18795 [0x86b508,0x8b4bb8), ./out/fuzz-lxc-config-read: Running 1 inputs 1 time(s) each. Running: ../minimized-from-740f56329efc60eab59b8194132b712a873e88a3 ==850885==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x6b3e7f in parse_byte_size_string /home/vagrant/lxc/src/lxc/string_utils.c:912:6 #1 0x550991 in set_config_console_size /home/vagrant/lxc/src/lxc/confile.c:2483:8 #2 0x5346e2 in parse_line /home/vagrant/lxc/src/lxc/confile.c:2962:9 #3 0x64b3cd in lxc_file_for_each_line_mmap /home/vagrant/lxc/src/lxc/parse.c:125:9 #4 0x53340c in lxc_config_read /home/vagrant/lxc/src/lxc/confile.c:3039:9 #5 0x4e7ec2 in LLVMFuzzerTestOneInput /home/vagrant/lxc/src/tests/fuzz-lxc-config-read.c:23:2 #6 0x44ad2c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x44ad2c) #7 0x42ca4d in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x42ca4d) #8 0x433af0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x433af0) #9 0x423ff6 in main (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x423ff6) #10 0x7f79bdc89081 in __libc_start_main (/lib64/libc.so.6+0x27081) #11 0x42402d in _start (/home/vagrant/lxc/out/fuzz-lxc-config-read+0x42402d) Uninitialized value was created by an allocation of 'dup' in the stack frame of function 'parse_byte_size_string' #0 0x6b3330 in parse_byte_size_string /home/vagrant/lxc/src/lxc/string_utils.c:901 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vagrant/lxc/src/lxc/string_utils.c:912:6 in parse_byte_size_string Exiting ``` Closes https://oss-fuzz.com/testcase-detail/5829890470445056 Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
Teemperor
added a commit
to Teemperor/lxc
that referenced
this issue
Jun 21, 2022
fuzz-lxc-cgroup-init currently fails for me with the input
```
lxc.cap.keep=0
```
with this report:
```
==640655==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x833c77 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3161:6
lxc#1 0xaa5fd6 in add_cap_entry /src/lxc/san_build/../src/lxc/confile.c:2462:9
lxc#2 0x9eb69c in set_config_cap_keep /src/lxc/san_build/../src/lxc/confile.c:2503:8
lxc#3 0x974a76 in parse_line /src/lxc/san_build/../src/lxc/confile.c:3115:9
lxc#4 0xea8cac in lxc_file_for_each_line_mmap /src/lxc/san_build/../src/lxc/parse.c:123:9
lxc#5 0x9700a1 in lxc_config_read /src/lxc/san_build/../src/lxc/confile.c:3192:9
lxc#6 0x4a3b50 in LLVMFuzzerTestOneInput /src/lxc/san_build/../src/tests/fuzz-lxc-cgroup-init.c:40:8
lxc#7 0x10556e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
lxc#8 0x1041372 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
lxc#9 0x1046bbc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9
lxc#10 0x106f7b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
lxc#11 0x7ffff7bc00b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
lxc#12 0x420a9d in _start (/home/fuzzer/oss-fuzz/build/out/lxc/fuzz-lxc-cgroup-init+0x420a9d)
Uninitialized value was created by an allocation of 'last_cap' in the stack frame of function 'parse_cap'
#0 0x832e30 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3131
```
The reason is that without libcap we parse_cap ends up comparing two
uninitialized values. See the snippet below:
```
int parse_cap(const char *cap_name, __u32 *cap)
{
int ret;
unsigned int res;
__u32 last_cap;
[...]
ret = lxc_caps_last_cap(&last_cap); // NOTE: 1. Call here.
if (ret) // Not taken as dummy lxc_caps_last_cap returned 0.
return -1;
if ((__u32)res > last_cap) // last_cap is uninitialized.
return -1;
*cap = (__u32)res;
return 0;
}
```
Root cause seems to be that the dummy `lxc_caps_last_cap` returns 0 but
doesn't set the last_cap value. This patch just returns -1 as an error code
to avoid the uninitialized read.
Note: When reproducing the bug you need to compile with O0 and *not* with O1
otherwise you will not see the report.
Teemperor
added a commit
to Teemperor/lxc
that referenced
this issue
Jun 21, 2022
fuzz-lxc-cgroup-init currently fails for me with the input
```
lxc.cap.keep=0
```
with this report:
```
==640655==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x833c77 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3161:6
lxc#1 0xaa5fd6 in add_cap_entry /src/lxc/san_build/../src/lxc/confile.c:2462:9
lxc#2 0x9eb69c in set_config_cap_keep /src/lxc/san_build/../src/lxc/confile.c:2503:8
lxc#3 0x974a76 in parse_line /src/lxc/san_build/../src/lxc/confile.c:3115:9
lxc#4 0xea8cac in lxc_file_for_each_line_mmap /src/lxc/san_build/../src/lxc/parse.c:123:9
lxc#5 0x9700a1 in lxc_config_read /src/lxc/san_build/../src/lxc/confile.c:3192:9
lxc#6 0x4a3b50 in LLVMFuzzerTestOneInput /src/lxc/san_build/../src/tests/fuzz-lxc-cgroup-init.c:40:8
lxc#7 0x10556e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
lxc#8 0x1041372 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
lxc#9 0x1046bbc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9
lxc#10 0x106f7b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
lxc#11 0x7ffff7bc00b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
lxc#12 0x420a9d in _start (/home/fuzzer/oss-fuzz/build/out/lxc/fuzz-lxc-cgroup-init+0x420a9d)
Uninitialized value was created by an allocation of 'last_cap' in the stack frame of function 'parse_cap'
#0 0x832e30 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3131
```
The reason is that without libcap we parse_cap ends up comparing two
uninitialized values. See the snippet below:
```
int parse_cap(const char *cap_name, __u32 *cap)
{
int ret;
unsigned int res;
__u32 last_cap;
[...]
ret = lxc_caps_last_cap(&last_cap); // NOTE: 1. Call here.
if (ret) // Not taken as dummy lxc_caps_last_cap returned 0.
return -1;
if ((__u32)res > last_cap) // last_cap is uninitialized.
return -1;
*cap = (__u32)res;
return 0;
}
```
Root cause seems to be that the dummy `lxc_caps_last_cap` returns 0 but
doesn't set the last_cap value. This patch just returns -1 as an error code
to avoid the uninitialized read.
Note: When reproducing the bug you need to compile with O0 and *not* with O1
otherwise you will not see the report.
Teemperor
added a commit
to Teemperor/lxc
that referenced
this issue
Jun 21, 2022
fuzz-lxc-cgroup-init currently fails for me with the input
```
lxc.cap.keep=0
```
with this report:
```
==640655==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x833c77 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3161:6
lxc#1 0xaa5fd6 in add_cap_entry /src/lxc/san_build/../src/lxc/confile.c:2462:9
lxc#2 0x9eb69c in set_config_cap_keep /src/lxc/san_build/../src/lxc/confile.c:2503:8
lxc#3 0x974a76 in parse_line /src/lxc/san_build/../src/lxc/confile.c:3115:9
lxc#4 0xea8cac in lxc_file_for_each_line_mmap /src/lxc/san_build/../src/lxc/parse.c:123:9
lxc#5 0x9700a1 in lxc_config_read /src/lxc/san_build/../src/lxc/confile.c:3192:9
lxc#6 0x4a3b50 in LLVMFuzzerTestOneInput /src/lxc/san_build/../src/tests/fuzz-lxc-cgroup-init.c:40:8
lxc#7 0x10556e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
lxc#8 0x1041372 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
lxc#9 0x1046bbc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9
lxc#10 0x106f7b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
lxc#11 0x7ffff7bc00b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
lxc#12 0x420a9d in _start (/home/fuzzer/oss-fuzz/build/out/lxc/fuzz-lxc-cgroup-init+0x420a9d)
Uninitialized value was created by an allocation of 'last_cap' in the stack frame of function 'parse_cap'
#0 0x832e30 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3131
```
The reason is that without libcap we parse_cap ends up comparing two
uninitialized values. See the snippet below:
```
int parse_cap(const char *cap_name, __u32 *cap)
{
int ret;
unsigned int res;
__u32 last_cap;
[...]
ret = lxc_caps_last_cap(&last_cap); // NOTE: 1. Call here.
if (ret) // Not taken as dummy lxc_caps_last_cap returned 0.
return -1;
if ((__u32)res > last_cap) // last_cap is uninitialized.
return -1;
*cap = (__u32)res;
return 0;
}
```
Root cause seems to be that the dummy `lxc_caps_last_cap` returns 0 but
doesn't set the last_cap value. This patch just returns -1 as an error code
to avoid the uninitialized read.
Note: When reproducing the bug you need to compile with O0 and *not* with O1
otherwise you will not see the report.
Signed-off-by: Raphael Isemann <teemperor@gmail.com>
stgraber
pushed a commit
that referenced
this issue
Jul 25, 2022
fuzz-lxc-cgroup-init currently fails for me with the input
```
lxc.cap.keep=0
```
with this report:
```
==640655==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x833c77 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3161:6
#1 0xaa5fd6 in add_cap_entry /src/lxc/san_build/../src/lxc/confile.c:2462:9
#2 0x9eb69c in set_config_cap_keep /src/lxc/san_build/../src/lxc/confile.c:2503:8
#3 0x974a76 in parse_line /src/lxc/san_build/../src/lxc/confile.c:3115:9
#4 0xea8cac in lxc_file_for_each_line_mmap /src/lxc/san_build/../src/lxc/parse.c:123:9
#5 0x9700a1 in lxc_config_read /src/lxc/san_build/../src/lxc/confile.c:3192:9
#6 0x4a3b50 in LLVMFuzzerTestOneInput /src/lxc/san_build/../src/tests/fuzz-lxc-cgroup-init.c:40:8
#7 0x10556e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#8 0x1041372 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
#9 0x1046bbc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9
#10 0x106f7b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#11 0x7ffff7bc00b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
#12 0x420a9d in _start (/home/fuzzer/oss-fuzz/build/out/lxc/fuzz-lxc-cgroup-init+0x420a9d)
Uninitialized value was created by an allocation of 'last_cap' in the stack frame of function 'parse_cap'
#0 0x832e30 in parse_cap /src/lxc/san_build/../src/lxc/conf.c:3131
```
The reason is that without libcap we parse_cap ends up comparing two
uninitialized values. See the snippet below:
```
int parse_cap(const char *cap_name, __u32 *cap)
{
int ret;
unsigned int res;
__u32 last_cap;
[...]
ret = lxc_caps_last_cap(&last_cap); // NOTE: 1. Call here.
if (ret) // Not taken as dummy lxc_caps_last_cap returned 0.
return -1;
if ((__u32)res > last_cap) // last_cap is uninitialized.
return -1;
*cap = (__u32)res;
return 0;
}
```
Root cause seems to be that the dummy `lxc_caps_last_cap` returns 0 but
doesn't set the last_cap value. This patch just returns -1 as an error code
to avoid the uninitialized read.
Note: When reproducing the bug you need to compile with O0 and *not* with O1
otherwise you will not see the report.
Signed-off-by: Raphael Isemann <teemperor@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
rc.conf, rc.sysinit.lxc, rc.shutdown.lxc, inittab are now longer required. Most software in Arch Linux required installation of the "base" group instead of individual packages from this group.
The text was updated successfully, but these errors were encountered: