Skip to content

Integrate su into util-linux #11

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
Merged
merged 106 commits into from
May 29, 2012
Merged

Integrate su into util-linux #11

merged 106 commits into from
May 29, 2012

Conversation

lnussel
Copy link
Contributor

@lnussel lnussel commented May 25, 2012

Integrate su into util-linux

meyering added 30 commits October 31, 1992 20:42
@meyering
Initial revision
0728090
@meyering
Initial revision
9678ebc
@meyering
Make still more file-scope variables `static'.
385fd9d
@meyering
all files: make most variables static and const when possible.
b4a5684 
declare lots of functions static.
@meyering
Convert static declarations of struct option to use new macros from
a261f05 
getopt.h: no_argument, required_argument, and optional_argument.
@meyering
merge with 1.8.1 + partial --version and --help
b6a55b2
@meyering
merge with 1.8.1b
9fd214f
@meyering
merge with 1.8.1d
217825f
@meyering
merge with 1.8.1g
bc7510e
@meyering
merge with 1.8.1h
7af6dac
@meyering
merge with 1.8.1i
e41cfda
@meyering
merge with 1.9
9ce9129
@meyering
.
a7f2355
@meyering
.
3e13ef4
@meyering
.
4e7c6e0
@meyering
.
e3feb4f
@meyering
.
99d439a
@meyering
.
4214f67
@meyering
.
e34290f
@meyering
merge with 1.10n2
8303e08
@meyering
.
f014992
@meyering
.
db90b9d
@meyering
* src/*.c: Include "error.h" instead of simply declaring
55eef5a 
	`void error ();'.
@meyering
(correct_password): Use memset instead of bzero.
742f505
@meyering
add 1995 to Copyright dates
070d354
@meyering
(usage): Add one- and two-line descriptions to --help output.
a36c9ac 
From Karl.
@meyering
Annotate localizable strings with _(...). From Franc,ois.
684cda5
@meyering
Indent cpp directives.
7e9dc9c
@meyering
s/non-zero/nonzero/g
3551197
@meyering
Remove NGROUPS_MAX junk. It wasn't being used.
6c3b4df
eggert and others added 14 commits August 21, 2006 07:30
@eggert
Add a bootstrap procedure, so that the CVS version contains fewer
5b6aef6 
files and we bootstrap the rest from gnulib, gettext, etc.
* README-cvs: New file.
* bootstrap: New file.
* bootstrap.conf: New file.
* .x-sc_trailing_blank: Remove config-log, .gdb-history.  Add .po.
* configure.ac (AC_PREREQ): Move here from m4/*.m4, for benefit
of gnulib-tool.
(gl_DEFAULT_POSIX2_VERSION, gl_USE_SYSTEM_EXTENSIONS, gl_PERL):
(gl_IGNORE_UNUSED_LIBRARIES): Remove; now done by gnulib.
(gl_EARLY): Add.
(gl_MACROS): Call just after gl_EARLY, just for clarity.
* src/c99-to-c98.diff: Remove patch to ls.c; no longer needed.
* src/kill.c (strtoimax): Remove decl.
* src/ls.c: Include "wcwidth.h" instead of rolling it ourselves.
* src/wc.c: Likewise.
* src/ls.c (sort_files): Rewrite to avoid need for C99-style
declaration, so that we don't need to patch this file.
* src/printf.c (strtoimax, strtoumax): Remove decls.
* src/su.c: Include getpass.h.
(getpass): remove.
* src/system.h: Include mempcpy.h, stpcpy.h, strpbrk.h.
Include inttypes.h unconditionally; remove decls it handles.
* lib/Makefile.am: include gnulib.mk, so that we can remove most of
this file.
(AM_CPPFLAGS): Don't mention -I$(srcdir), since that's now done
for us.
(noinst_LIBRARIES, LDDADD, DEFS): Remove.
(libcoreutils_a_SOURCES): Trim down greatly, just to the files
that aren't in gnulib.
Remove defns gnulib does for us.
* m4/check-decl.m4 (gl_CHECK_DECLS):
Don't include stdio.h, string.h, stdlib.h, unistd.h, sys/time.h,
time.h.  Use AC_CHECK_DECLS_ONCE for free, getenv, geteuid, getlogin,
getuid, lseek, malloc, memchr, realloc.  Don't check for getutent,
memrchr, nanosleep, stpcpy, strndup, strnlen, strstr, strtoul,
strtoull.
(_gl_DECL_HEADERS): Remove; all uses removed.
* m4/jm-macros.m4 (gl_MACROS): Move AC_PREREQ into configure.ac
for the benefit of gnulib-tool.  Call gl_INIT.
Do not call or require macros that gnulib will handle for us.
Don't check for fchmod, hasmntopt, isascii, lchown, listmntent,
mempcpy, realpath, wcrtomb, tzset.
(gl_CHECK_ALL_HEADERS): Don't check for sys/statvfs.h, sys/vfs.h,
sys/mount.h.
(gl_CHECK_ALL_TYPES): Require AC_TYPE_UNSIGNED_LONG_LONG_INT.
Don't check for struct stat.st_blksize.
Don't require AC_STRUCT_ST_DM_MODE, gt_TYPE_SSIZE_T,
gl_AC_TYPE_UINT32_T, gl_AC_TYPE_UINTMAX_T, gl_AC_TYPE_UINTPTR_T,
gl_AC_TYPE_UNSIGNED_LONG_LONG.
* m4/prereq.m4 (gl_PREREQ): Require gl_FUNC_XFTS, gl_ROOT_DEV_INO.
Don't require macros that gnulib does for us.
* m4/stat-prog.m4 (cu_PREREQ_STAT_PROG): Don't check for
sys/sysmacros.h.  Don't check for statvfs.  Use AC_CHECK_HEADERS_ONCE
for netinet/in.h, nfs/nfs_clnt.h, nfs/vfs.h.
Don't require gl_AC_TYPE_LONG_LONG, gt_HEADER_INTTYPES_H.
@eggert
Don't include dirname.h, since system.h does it now.
7943f79
@meyering
Help translators include translation team's web or email address.
ce5f2f2 
* src/system.h (emit_bug_reporting_address): New function.
* src/base64.c: Use it rather than a literal printf.
* src/basename.c, src/cat.c, src/chgrp.c, src/chmod.c:
* src/chown.c, src/chroot.c, src/cksum.c, src/comm.c, src/cp.c:
* src/csplit.c, src/cut.c, src/date.c, src/dd.c, src/df.c:
* src/dircolors.c, src/dirname.c, src/du.c, src/echo.c, src/env.c:
* src/expand.c, src/expr.c, src/factor.c, src/fmt.c, src/fold.c:
* src/head.c, src/hostid.c, src/hostname.c, src/id.c, src/install.c:
* src/join.c, src/kill.c, src/link.c, src/ln.c, src/logname.c:
* src/ls.c, src/md5sum.c, src/mkdir.c, src/mkfifo.c, src/mknod.c:
* src/mv.c, src/nice.c, src/nl.c, src/nohup.c, src/od.c:
* src/paste.c, src/pathchk.c, src/pinky.c, src/pr.c, src/printenv.c:
* src/printf.c, src/ptx.c, src/pwd.c, src/readlink.c, src/rm.c:
* src/rmdir.c, src/seq.c, src/setuidgid.c, src/shred.c, src/shuf.c:
* src/sleep.c, src/sort.c, src/split.c, src/stat.c, src/stty.c:
* src/su.c, src/sum.c, src/sync.c, src/system.h, src/tac.c:
* src/tail.c, src/tee.c, src/test.c, src/touch.c, src/tr.c:
* src/true.c, src/tsort.c, src/tty.c, src/uname.c, src/unexpand.c:
* src/uniq.c, src/unlink.c, src/uptime.c, src/users.c, src/wc.c:
* src/who.c, src/whoami.c, src/yes.c: Likewise.
@lnussel
merge coreutils' last GPL2 version of su.c
d6586bf
@lnussel
pam support for su
8171142
@lnussel
log all su attempts
b14d022
@lnussel
set sane default path
a9980c8
@lnussel
honor settings in /etc/default/su resp /etc/login.defs
589554a
@bitstreamout @lnussel
make sure /sbin resp /usr/sbin are in PATH
a6fdd3f
@twaugh @lnussel
call setsid() when called with -c
c6a1746 
Prevents command injection via TIOCSTI

https://bugzilla.redhat.com/show_bug.cgi?id=173008
@lnussel
make su build as part of util-linux
ff6b15d
@lnussel
remove non pam code
c92880e
@lnussel
syslog always
f29fc7e
@lnussel
use existing logindefs.c and pathnames.h
9c44ac5 
I'm not sure having /usr/local in _PATH_DEFPATH_ROOT and even putting it
in front is such a good idea though. /usr/local might be on NFS so could
prevent root from logging in if the network is down.
@karelzak karelzak merged commit 9c44ac5 into util-linux:master May 29, 2012
evverx added a commit to evverx/util-linux that referenced this pull request Jun 25, 2020
@evverx
add a fuzzer for mnt_table_parse_stream
08e74af 
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:

systemd/systemd#12252 (comment)
systemd/systemd#8504

so it seems to be a good idea to continuously fuzz that particular
function.

The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
    #1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
    #2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
    #3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
    #4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
    util-linux#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
    util-linux#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
    util-linux#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
    util-linux#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
    util-linux#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
    util-linux#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
    util-linux#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```

Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/
evverx added a commit to evverx/util-linux that referenced this pull request Jun 25, 2020
@evverx
add a fuzzer for mnt_table_parse_stream
a0a6887 
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:

systemd/systemd#12252 (comment)
systemd/systemd#8504

so it seems to be a good idea to continuously fuzz that particular
function.

The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
    #1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
    #2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
    #3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
    #4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
    util-linux#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
    util-linux#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
    util-linux#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
    util-linux#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
    util-linux#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
    util-linux#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
    util-linux#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```

Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/
evverx added a commit to evverx/util-linux that referenced this pull request Jun 27, 2020
@evverx
add a fuzzer for mnt_table_parse_stream
a8bebab 
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:

systemd/systemd#12252 (comment)
systemd/systemd#8504

so it seems to be a good idea to continuously fuzz that particular
function.

The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
    #1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
    #2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
    #3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
    #4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
    util-linux#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
    util-linux#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
    util-linux#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
    util-linux#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
    util-linux#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
    util-linux#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
    util-linux#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```

Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/
evverx added a commit to evverx/util-linux that referenced this pull request Jul 28, 2020
@evverx
add a fuzzer for mnt_table_parse_stream
5e69319 
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:

systemd/systemd#12252 (comment)
systemd/systemd#8504

so it seems to be a good idea to continuously fuzz that particular
function.

The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
    #1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
    #2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
    #3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
    #4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
    util-linux#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
    util-linux#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
    util-linux#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
    util-linux#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
    util-linux#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
    util-linux#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
    util-linux#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```

Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/
evverx added a commit to evverx/util-linux that referenced this pull request Jul 30, 2020
@evverx
tests: add a fuzzer for mnt_table_parse_stream
28aafae 
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:

systemd/systemd#12252 (comment)
systemd/systemd#8504

so it seems to be a good idea to continuously fuzz that particular
function.

The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
    #1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
    #2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
    #3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
    #4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
    util-linux#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
    util-linux#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
    util-linux#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
    util-linux#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
    util-linux#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
    util-linux#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
    util-linux#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```

Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/
evverx added a commit to evverx/util-linux that referenced this pull request Jul 30, 2020
@evverx
tests: add a fuzzer for mnt_table_parse_stream
bdaaebd 
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:

systemd/systemd#12252 (comment)
systemd/systemd#8504

so it seems to be a good idea to continuously fuzz that particular
function.

The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
    #1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
    #2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
    #3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
    #4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
    util-linux#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
    util-linux#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
    util-linux#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
    util-linux#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
    util-linux#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
    util-linux#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
    util-linux#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```

Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/

Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
evverx added a commit to evverx/util-linux that referenced this pull request Aug 6, 2020
@evverx
tests: add a fuzzer for mnt_table_parse_stream
ccdc47b 
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:

systemd/systemd#12252 (comment)
systemd/systemd#8504

so it seems to be a good idea to continuously fuzz that particular
function.

The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
    #1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
    #2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
    #3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
    #4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
    util-linux#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
    util-linux#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
    util-linux#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
    util-linux#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
    util-linux#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
    util-linux#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
    util-linux#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)

SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```

Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/

Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
evverx added a commit to evverx/util-linux that referenced this pull request Aug 17, 2020
@evverx
tests: cover the code parsing comments
d772058 
It seems to be failing with
```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==13==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000055f428 bp 0x7ffc3743a170 sp 0x7ffc3743a080 T0)
==13==The signal is caused by a WRITE memory access.
==13==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
    #0 0x55f428 in mnt_table_parse_next /src/util-linux/libmount/src/tab_parse.c:587:6
    #1 0x55c200 in __table_parse_stream /src/util-linux/libmount/src/tab_parse.c:737:8
    #2 0x55be38 in mnt_table_parse_stream /src/util-linux/libmount/src/tab_parse.c:809:8
    #3 0x5511ff in LLVMFuzzerTestOneInput /src/util-linux/libmount/src/fuzz.c:21:16
    #4 0x458a31 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:558:15
    util-linux#5 0x458175 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:470:3
    util-linux#6 0x45a117 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:770:7
    util-linux#7 0x45a319 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:799:3
    util-linux#8 0x44a055 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:846:6
    util-linux#9 0x471bf2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
    util-linux#10 0x7fe3bd93b83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
    util-linux#11 0x41f208 in _start (/out/test_mount_fuzz+0x41f208)

DEDUP_TOKEN: mnt_table_parse_next--__table_parse_stream--mnt_table_parse_stream
```
@rscottha rscottha mentioned this pull request Mar 19, 2023
Closed
t-8ch added a commit to t-8ch/util-linux that referenced this pull request Nov 20, 2023
@t-8ch
lsfd: avoid undefined behavior
51cd4ab 
Passing a pointer to a pid_t to tfind() which expects it to be backed by
a 'struct proc' evokes undefined behavior.
This triggers UBSAN as shown below.

Instead pass a proper 'struct proc'.

../misc-utils/lsfd.c:513:27: runtime error: member access within misaligned address 0x7ffe9ee6495c for type 'struct proc', which requires 8 byte alignment
0x7ffe9ee6495c: note: pointer points here
  1a 1a 1a 1a 01 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  d0 49 e6 9e fe 7f 00 00
              ^
    #0 0x56159cfa4a3b in proc_tree_compare ../misc-utils/lsfd.c:513
    util-linux#1 0x7f9dd4d2d743 in __tfind (/usr/lib/libc.so.6+0x10f743) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#2 0x56159cfa4ac3 in get_proc ../misc-utils/lsfd.c:518
    util-linux#3 0x56159cfe217b in anon_pidfd_get_name ../misc-utils/lsfd-unkn.c:203
    util-linux#4 0x56159cfe1040 in unkn_fill_column ../misc-utils/lsfd-unkn.c:93
    util-linux#5 0x56159cfaaa37 in fill_column ../misc-utils/lsfd.c:1178
    util-linux#6 0x56159cfaaac5 in convert_file ../misc-utils/lsfd.c:1193
    util-linux#7 0x56159cfaac4f in convert ../misc-utils/lsfd.c:1212
    util-linux#8 0x56159cfb2b54 in main ../misc-utils/lsfd.c:2317
    util-linux#9 0x7f9dd4c45ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#10 0x7f9dd4c45d89 in __libc_start_main (/usr/lib/libc.so.6+0x27d89) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#11 0x56159cfa3c34 in _start (util-linux/build-meson/lsfd+0x41c34) (BuildId: 35fece1a205f96a2dbfe7a0e93b658530de675c4)

Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
@t-8ch t-8ch mentioned this pull request Nov 20, 2023
Merged
t-8ch added a commit to t-8ch/util-linux that referenced this pull request Nov 20, 2023
@t-8ch
lsfd: avoid undefined behavior
816109f 
Passing a pointer to a different datatype to tfind() then were inserted
evokes undefines behavior.
This triggers UBSAN as shown below.

Instead pass the proper structs.

```
../misc-utils/lsfd.c:513:27: runtime error: member access within misaligned address 0x7ffe9ee6495c for type 'struct proc', which requires 8 byte alignment
0x7ffe9ee6495c: note: pointer points here
  1a 1a 1a 1a 01 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  d0 49 e6 9e fe 7f 00 00
              ^
    #0 0x56159cfa4a3b in proc_tree_compare ../misc-utils/lsfd.c:513
    util-linux#1 0x7f9dd4d2d743 in __tfind (/usr/lib/libc.so.6+0x10f743) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#2 0x56159cfa4ac3 in get_proc ../misc-utils/lsfd.c:518
    util-linux#3 0x56159cfe217b in anon_pidfd_get_name ../misc-utils/lsfd-unkn.c:203
    util-linux#4 0x56159cfe1040 in unkn_fill_column ../misc-utils/lsfd-unkn.c:93
    util-linux#5 0x56159cfaaa37 in fill_column ../misc-utils/lsfd.c:1178
    util-linux#6 0x56159cfaaac5 in convert_file ../misc-utils/lsfd.c:1193
    util-linux#7 0x56159cfaac4f in convert ../misc-utils/lsfd.c:1212
    util-linux#8 0x56159cfb2b54 in main ../misc-utils/lsfd.c:2317
    util-linux#9 0x7f9dd4c45ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#10 0x7f9dd4c45d89 in __libc_start_main (/usr/lib/libc.so.6+0x27d89) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#11 0x56159cfa3c34 in _start (util-linux/build-meson/lsfd+0x41c34) (BuildId: 35fece1a205f96a2dbfe7a0e93b658530de675c4)
```

Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
karelzak pushed a commit to karelzak/util-linux-work that referenced this pull request Nov 30, 2023
@t-8ch @karelzak
lsfd: avoid undefined behavior
192d8aa 
Passing a pointer to a different datatype to tfind() then were inserted
evokes undefines behavior.
This triggers UBSAN as shown below.

Instead pass the proper structs.

```
../misc-utils/lsfd.c:513:27: runtime error: member access within misaligned address 0x7ffe9ee6495c for type 'struct proc', which requires 8 byte alignment
0x7ffe9ee6495c: note: pointer points here
  1a 1a 1a 1a 01 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  d0 49 e6 9e fe 7f 00 00
              ^
    #0 0x56159cfa4a3b in proc_tree_compare ../misc-utils/lsfd.c:513
    #1 0x7f9dd4d2d743 in __tfind (/usr/lib/libc.so.6+0x10f743) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    #2 0x56159cfa4ac3 in get_proc ../misc-utils/lsfd.c:518
    #3 0x56159cfe217b in anon_pidfd_get_name ../misc-utils/lsfd-unkn.c:203
    util-linux#4 0x56159cfe1040 in unkn_fill_column ../misc-utils/lsfd-unkn.c:93
    util-linux#5 0x56159cfaaa37 in fill_column ../misc-utils/lsfd.c:1178
    util-linux#6 0x56159cfaaac5 in convert_file ../misc-utils/lsfd.c:1193
    util-linux#7 0x56159cfaac4f in convert ../misc-utils/lsfd.c:1212
    util-linux#8 0x56159cfb2b54 in main ../misc-utils/lsfd.c:2317
    util-linux#9 0x7f9dd4c45ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#10 0x7f9dd4c45d89 in __libc_start_main (/usr/lib/libc.so.6+0x27d89) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#11 0x56159cfa3c34 in _start (util-linux/build-meson/lsfd+0x41c34) (BuildId: 35fece1a205f96a2dbfe7a0e93b658530de675c4)
```

Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
(cherry picked from commit 816109f)
ahmed-masud pushed a commit to safai-labs/util-linux that referenced this pull request Feb 23, 2024
@t-8ch @ahmed-masud
lsfd: avoid undefined behavior
49c6b2c 
Passing a pointer to a different datatype to tfind() then were inserted
evokes undefines behavior.
This triggers UBSAN as shown below.

Instead pass the proper structs.

```
../misc-utils/lsfd.c:513:27: runtime error: member access within misaligned address 0x7ffe9ee6495c for type 'struct proc', which requires 8 byte alignment
0x7ffe9ee6495c: note: pointer points here
  1a 1a 1a 1a 01 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  d0 49 e6 9e fe 7f 00 00
              ^
    #0 0x56159cfa4a3b in proc_tree_compare ../misc-utils/lsfd.c:513
    #1 0x7f9dd4d2d743 in __tfind (/usr/lib/libc.so.6+0x10f743) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    #2 0x56159cfa4ac3 in get_proc ../misc-utils/lsfd.c:518
    util-linux#3 0x56159cfe217b in anon_pidfd_get_name ../misc-utils/lsfd-unkn.c:203
    util-linux#4 0x56159cfe1040 in unkn_fill_column ../misc-utils/lsfd-unkn.c:93
    util-linux#5 0x56159cfaaa37 in fill_column ../misc-utils/lsfd.c:1178
    util-linux#6 0x56159cfaaac5 in convert_file ../misc-utils/lsfd.c:1193
    util-linux#7 0x56159cfaac4f in convert ../misc-utils/lsfd.c:1212
    util-linux#8 0x56159cfb2b54 in main ../misc-utils/lsfd.c:2317
    util-linux#9 0x7f9dd4c45ccf  (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#10 0x7f9dd4c45d89 in __libc_start_main (/usr/lib/libc.so.6+0x27d89) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
    util-linux#11 0x56159cfa3c34 in _start (util-linux/build-meson/lsfd+0x41c34) (BuildId: 35fece1a205f96a2dbfe7a0e93b658530de675c4)
```

Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
@biubiuzy biubiuzy mentioned this pull request Mar 18, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@lnussel @karelzak @meyering @eggert @bitstreamout @twaugh