Skip to content

Remove use of __P #8

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 2 commits into from
May 23, 2012
Merged

Remove use of __P #8

merged 2 commits into from
May 23, 2012

Conversation

jhuntwork
Copy link
Contributor

...s, but that is not even possible with the modern-day codebase. Moreover, it breaks compiling on libcs that do not define this legacy implementation-internal macro.

jhuntwork added 2 commits May 13, 2012 16:32
@jhuntwork
Remove use of __P. Its intended usage was to support pre-ANSI C compi…
1c935e7 
…lers, but that is not even possible with the modern-day codebase. Moreover, it breaks compiling on libcs that do not define this legacy implementation-internal macro.
@jhuntwork
Use POSIX regcomp and regexec over obsolete BSD re_comp and re_exec
596007e
@karelzak
Copy link
Collaborator

On Sun, May 13, 2012 at 09:33:32AM -0700, Jeremy Huntwork wrote:

...s, but that is not even possible with the modern-day codebase.
Moreover, it breaks compiling on libcs that do not define this
legacy implementation-internal macro.

Applied. Please, use Signed-off-by: line in your commit messages next
time.

Thanks.

Karel

Karel Zak kzak@redhat.com
http://karelzak.blogspot.com

@karelzak karelzak merged commit 596007e into util-linux:master May 23, 2012
@jhuntwork
Copy link
Contributor Author

On 5/23/12 3:41 AM, Karel Zak wrote:

On Sun, May 13, 2012 at 09:33:32AM -0700, Jeremy Huntwork wrote:

...s, but that is not even possible with the modern-day codebase.
Moreover, it breaks compiling on libcs that do not define this
legacy implementation-internal macro.

Applied. Please, use Signed-off-by: line in your commit messages next
time.

Great, thanks. Yes, I'll do that.

JH

karelzak pushed a commit that referenced this pull request Nov 18, 2014
@kerolasa @karelzak
libmount: fix memory overflow [AddressSanitizer]
e3c2718 
==10918==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffd795b680 at pc 0x0000004447c6 bp 0x7fffd795b3e0 sp 0x7fffd795ab78
WRITE of size 129 at 0x7fffd795b680 thread T0
    #0 0x4447c5 in scanf_common(void*, int, bool, char const*, __va_list_tag*) (/home/src/util-linux/.libs/lt-mount+0x4447c5)
    #1 0x445892 in sscanf (/home/src/util-linux/.libs/lt-mount+0x445892)
    #2 0x7fe78709a3d3 in get_filesystems /home/src/util-linux/libmount/src/utils.c:581:7
    #3 0x7fe78709a1ba in mnt_get_filesystems /home/src/util-linux/libmount/src/utils.c:622:7
    #4 0x7fe7870aa78f in do_mount_by_pattern /home/src/util-linux/libmount/src/context_mount.c:833:7
    #5 0x7fe7870a9534 in mnt_context_do_mount /home/src/util-linux/libmount/src/context_mount.c:951:9
    #6 0x7fe7870aab2b in mnt_context_mount /home/src/util-linux/libmount/src/context_mount.c:1051:8
    #7 0x4ba9f5 in main /home/src/util-linux/sys-utils/mount.c:1107:7
    #8 0x7fe785caa03f in __libc_start_main (/usr/lib/libc.so.6+0x2003f)
    #9 0x4b9f9c in _start (/home/src/util-linux/.libs/lt-mount+0x4b9f9c)

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Karel Zak <kzak@redhat.com>
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
```
@Ataraxiall Ataraxiall mentioned this pull request Jul 27, 2021
Closed
@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.
2 participants
@jhuntwork @karelzak