fdisk: build fails on IA32 architectures #3

morfoh · 2012-02-15T12:57:13Z

fdisk fails for for all tested arch/cpu types emitting following error:

In file included from fdiskbsdlabel.c:62:0:
fdiskbsdlabel.h:61:2: error: #error unknown architecture
fdiskbsdlabel.c: In function 'bselect':
fdiskbsdlabel.c:180:44: error: 'BSD_LABELSECTOR' undeclared (first use in this function)
fdiskbsdlabel.c:180:44: note: each undeclared identifier is reported only once for each function it appears in
fdiskbsdlabel.c: In function 'xbsd_write_bootstrap':
fdiskbsdlabel.c:539:24: error: 'BSD_LABELSECTOR' undeclared (first use in this function)
fdiskbsdlabel.c: In function 'xbsd_readlabel':
fdiskbsdlabel.c:744:28: error: 'BSD_LABELSECTOR' undeclared (first use in this function)
fdiskbsdlabel.c:744:60: error: 'BSD_LABELOFFSET' undeclared (first use in this function)
fdiskbsdlabel.c: In function 'xbsd_writelabel':
fdiskbsdlabel.c:769:32: error: 'BSD_LABELSECTOR' undeclared (first use in this function)
fdiskbsdlabel.c:780:61: error: 'BSD_LABELOFFSET' undeclared (first use in this function)

make[2]: *** [fdisk-fdiskbsdlabel.o] Error 1

Tested architectures:

i486 using gcc -march=i486
i586 using gcc -march=pentium-mmx
i686 using gcc -march={pentiumpro,pentium2,pentium3,pentium-m,pentium4}

Tested with following major toolchain components:

binutils 2.21.53.0.2
gcc 4.6.2
glibc 2.14.1

karelzak · 2012-11-07T14:44:49Z

Fixed by upstream commit 90e5767.

#0 recount_geometry at libfdisk/src/alignment.c:143 #1 fdisk_discover_geometry at libfdisk/src/alignment.c:205 #2 fdisk_context_assign_device at libfdisk/src/context.c:173 #3 print_partition_table_from_option at fdisks/fdisk.c:924 References: https://bugzilla.redhat.com/show_bug.cgi?id=1005566 Signed-off-by: Karel Zak <kzak@redhat.com>

==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>

==3218==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa577e2b0 at pc 0x4501f9 bp 0x7fffa577e130 sp 0x7fffa577e108 WRITE of size 112 at 0x7fffa577e2b0 thread T0 #0 0x4501f8 in shmctl /home/users/aadgrand/LLVM/releases/ubuntu/final/llvm.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:2502 #1 0x48bd13 in ipc_shm_get_info /home/travis/build/kerolasa/lelux-utiliteetit/sys-utils/ipcutils.c:157 #2 0x488884 in do_shm /home/travis/build/kerolasa/lelux-utiliteetit/sys-utils/ipcs.c:279 #3 0x4844a8 in main /home/travis/build/kerolasa/lelux-utiliteetit/sys-utils/ipcs.c:175 #4 0x2afb3f8c176c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c) #5 0x48408c in _start (/home/travis/build/kerolasa/lelux-utiliteetit/ipcs+0x48408c) Signed-off-by: Sami Kerola <kerolasa@iki.fi>

text-utils/colcrt.c:205:10: runtime error: index -1 out of bounds for type 'wchar_t [133]' SUMMARY: AddressSanitizer: undefined-behavior text-utils/colcrt.c:205 ================================================================= ==2357==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000013811b0 at pc 0x0000004e2514 bp 0x7ffdf6ba4450 sp 0x7ffdf6ba4448 READ of size 4 at 0x0000013811b0 thread T0 #0 0x4e2513 in colcrt /home/src/util-linux/text-utils/colcrt.c:213:8 #1 0x4e17d4 in main /home/src/util-linux/text-utils/colcrt.c:139:3 #2 0x7fb77236960f in __libc_start_main (/usr/lib/libc.so.6+0x2060f) #3 0x4362c8 in _start (/home/src/util-linux/colcrt+0x4362c8) Reported-by: Alaa Mubaied <alaamubaied@gmail.com> Signed-off-by: Sami Kerola <kerolasa@iki.fi>

==2807==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000013a31f0 at pc 0x0000004e3047 bp 0x7fffcb7df8d0 sp 0x7fffcb7df8c8 READ of size 4 at 0x0000013a31f0 thread T0 #0 0x4e3046 in move /home/src/util-linux/text-utils/colcrt.c:309:13 #1 0x4e25b1 in pflush /home/src/util-linux/text-utils/colcrt.c:264:3 #2 0x4e246d in colcrt /home/src/util-linux/text-utils/colcrt.c:157:4 #3 0x4e17d4 in main /home/src/util-linux/text-utils/colcrt.c:141:3 #4 0x7fb0cb2ee60f in __libc_start_main (/usr/lib/libc.so.6+0x2060f) #5 0x4362c8 in _start (/home/src/util-linux/colcrt+0x4362c8) 0x0000013a31f0 is located 0 bytes to the right of global variable 'page' defined in 'text-utils/colcrt.c:73:9' (0x1380b40) of size 140976 SUMMARY: AddressSanitizer: global-buffer-overflow /home/src/util-linux/text-utils/colcrt.c:309 move And another crash: ==4578==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000013a3d24 at pc 0x0000004e2510 bp 0x7ffc9257b0e0 sp 0x7ffc9257b0d8 READ of size 4 at 0x0000013a3d24 thread T0 #0 0x4e250f in colcrt /home/src/util-linux/text-utils/colcrt.c:218:8 #1 0x4e17d4 in main /home/src/util-linux/text-utils/colcrt.c:141:3 #2 0x7fe0ac94160f in __libc_start_main (/usr/lib/libc.so.6+0x2060f) #3 0x4362c8 in _start (/home/src/util-linux/colcrt+0x4362c8) 0x0000013a3d24 is located 8 bytes to the right of global variable 'page' defined in 'text-utils/colcrt.c:73:9' (0x1381240) of size 142044 SUMMARY: AddressSanitizer: global-buffer-overflow /home/src/util-linux/text-utils/colcrt.c:218 colcrt Reported-by: Alaa Mubaied <alaamubaied@gmail.com> Signed-off-by: Sami Kerola <kerolasa@iki.fi>

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/

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>

Looks like those specifiers haven't been used since 6c9ab25 (where sscanf was removed) was merged. This should help to get util-linux to compile with MSan. Currently it's failing with ``` ... configure: error: libmount selected, but required scanf string alloc modifier not available ... configure:20240: ./conftest ==116617==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x496fd6 in main /home/vagrant/util-linux/conftest.c:171:6 #1 0x7f5eb85ea1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #2 0x41c2cd in _start (/home/vagrant/util-linux/conftest+0x41c2cd) SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vagrant/util-linux/conftest.c:171:6 in main Exiting configure:20240: $? = 77 ... configure:20265: $? = 0 configure:20265: ./conftest MemorySanitizer: bad pointer 0x000000496e60 ==116627==MemorySanitizer CHECK failed: /builddir/build/BUILD/compiler-rt-9.0.1.src/lib/msan/../sanitizer_common/sanitizer_allocator_secondary.h:177 "((IsAligned(reinterpret_cast<uptr>(p), page_size_))) != (0)" (0x0, 0x0) #0 0x41d1d8 in MsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/vagrant/util-linux/conftest+0x41d1d8) #1 0x484e1e in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/vagrant/util-linux/conftest+0x484e1e) #2 0x42066c in __msan::MsanDeallocate(__sanitizer::StackTrace*, void*) (/home/vagrant/util-linux/conftest+0x42066c) #3 0x424bc9 in free (/home/vagrant/util-linux/conftest+0x424bc9) #4 0x496fae in main /home/vagrant/util-linux/conftest.c:173:2 util-linux#5 0x7f2245f311a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) util-linux#6 0x41c2cd in _start (/home/vagrant/util-linux/conftest+0x41c2cd) configure:20265: $? = 77 configure: program exited with status 77 ... | } configure:22568: result: no configure:22926: error: libmount selected, but required scanf string alloc modifier not available ```

Looks like those specifiers haven't been used since 6c9ab25 (where sscanf was removed) was merged. This should help to get util-linux to compile with MSan. Currently it's failing with ``` ... configure: error: libmount selected, but required scanf string alloc modifier not available ... configure:20240: ./conftest ==116617==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x496fd6 in main /home/vagrant/util-linux/conftest.c:171:6 #1 0x7f5eb85ea1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #2 0x41c2cd in _start (/home/vagrant/util-linux/conftest+0x41c2cd) SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vagrant/util-linux/conftest.c:171:6 in main Exiting configure:20240: $? = 77 ... configure:20265: $? = 0 configure:20265: ./conftest MemorySanitizer: bad pointer 0x000000496e60 ==116627==MemorySanitizer CHECK failed: /builddir/build/BUILD/compiler-rt-9.0.1.src/lib/msan/../sanitizer_common/sanitizer_allocator_secondary.h:177 "((IsAligned(reinterpret_cast<uptr>(p), page_size_))) != (0)" (0x0, 0x0) #0 0x41d1d8 in MsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/vagrant/util-linux/conftest+0x41d1d8) #1 0x484e1e in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/vagrant/util-linux/conftest+0x484e1e) #2 0x42066c in __msan::MsanDeallocate(__sanitizer::StackTrace*, void*) (/home/vagrant/util-linux/conftest+0x42066c) #3 0x424bc9 in free (/home/vagrant/util-linux/conftest+0x424bc9) #4 0x496fae in main /home/vagrant/util-linux/conftest.c:173:2 util-linux#5 0x7f2245f311a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) util-linux#6 0x41c2cd in _start (/home/vagrant/util-linux/conftest+0x41c2cd) configure:20265: $? = 77 configure: program exited with status 77 ... | } configure:22568: result: no configure:22926: error: libmount selected, but required scanf string alloc modifier not available ``` Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>

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 ```

Looks like those specifiers haven't been used since 6c9ab25 (where sscanf was removed) was merged. This should help to get util-linux to compile with MSan. Currently it's failing with ``` ... configure: error: libmount selected, but required scanf string alloc modifier not available ... configure:20240: ./conftest ==116617==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x496fd6 in main /home/vagrant/util-linux/conftest.c:171:6 #1 0x7f5eb85ea1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #2 0x41c2cd in _start (/home/vagrant/util-linux/conftest+0x41c2cd) SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vagrant/util-linux/conftest.c:171:6 in main Exiting configure:20240: $? = 77 ... configure:20265: $? = 0 configure:20265: ./conftest MemorySanitizer: bad pointer 0x000000496e60 ==116627==MemorySanitizer CHECK failed: /builddir/build/BUILD/compiler-rt-9.0.1.src/lib/msan/../sanitizer_common/sanitizer_allocator_secondary.h:177 "((IsAligned(reinterpret_cast<uptr>(p), page_size_))) != (0)" (0x0, 0x0) #0 0x41d1d8 in MsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/vagrant/util-linux/conftest+0x41d1d8) #1 0x484e1e in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/vagrant/util-linux/conftest+0x484e1e) #2 0x42066c in __msan::MsanDeallocate(__sanitizer::StackTrace*, void*) (/home/vagrant/util-linux/conftest+0x42066c) #3 0x424bc9 in free (/home/vagrant/util-linux/conftest+0x424bc9) #4 0x496fae in main /home/vagrant/util-linux/conftest.c:173:2 #5 0x7f2245f311a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #6 0x41c2cd in _start (/home/vagrant/util-linux/conftest+0x41c2cd) configure:20265: $? = 77 configure: program exited with status 77 ... | } configure:22568: result: no configure:22926: error: libmount selected, but required scanf string alloc modifier not available ``` Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>

Close util-linux#1637. The test cases assumed the file descriptor util-linux#3 was not occupied. As reported in util-linux#1637, the assumption was wrong. This new code assigns the file descriptor util-linux#3 explicitly with dup2 as the other test cases did. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This option affects list of visible columns, so it's better to apply it before any other flags, because "-1" placeholder depends on visible columns. For example: echo "A B C D" | column --table --table-maxout --table-right -1 --table-hide 4 needs to hide column #4 (D) and align #3 (C) to the right. Signed-off-by: Karel Zak <kzak@redhat.com>

If the fmt being parsed by block_size is exactly '%', *++fmt is the terminator and strchr will return a valid pointer to the terminator of spec rather than NULL, the while condition will pass and subsequent strchr will read past the end of fmt until a spec character is found again ASAN aborts with the following error on the first buffer overread: AddressSanitizer: heap-buffer-overflow on address 0x602000000212 at pc 0x55bf1c4b2d78 bp 0x7ffe33c8cff0 sp 0x7ffe33c8cfe0 READ of size 1 at 0x602000000212 thread T0 #0 0x55bf1c4b2d77 in block_size ../text-utils/hexdump-parse.c:207 util-linux#1 0x55bf1c4ad36f in main ../text-utils/hexdump.c:214 util-linux#2 0x7f15f063c78f (/usr/lib/libc.so.6+0x2378f) util-linux#3 0x7f15f063c849 in __libc_start_main (/usr/lib/libc.so.6+0x23849) util-linux#4 0x55bf1c4ac6c4 in _start (../build/hexdump+0x86c4)

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>

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>

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)

Submission to Project: util-linux Open Incident: util-linux#2609 at github.com/util-linux/issues/2609 Component: util-linux/sys-utils File: dmesg.c Code level patch applied against: 2.39.3 - latest code pulled from git.github.com:util-linux/util-linux.git Revision: #1 on 2023/12/08 per Review from Karel Zak Revision: #2 on 2023/12/12 Adjust line offsets for master update and Add caller_id_size init to dmesg -K Revision: #3 on 2023/12/12 Use of sizeof for cidbuf and limit search for caller_id to dmesg prefix to msg text Add support to standard dmesg command for the optional Linux Kernel debug CONFIG option PRINTK_CALLER which adds an optional dmesg field that contains the Thread Id or CPU Id that is issuing the printk to add the message to the kernel ring buffer. This makes debugging simpler as dmesg entries for a specific thread or CPU can be recognized. The dmesg -S using the old syslog interface supports printing the PRINTK_CALLER field but currently standard dmesg does not support printing the field if present. There are utilities that use dmesg and so it would be optimal if dmesg supported PRINTK_CALLER as well. The additional field provided by PRINTK_CALLER is only present if it was configured for the Linux kernel where the dmesg command is run. It is a debug option and not configured by default so the dmesg output will only change for those kernels where the option was configured when the kernel was built. For users who went to the trouble to configure PRINTK_CALLER and have the extra field available for debugging, having dmesg print the field is very helpful. Size of the PRINTK_CALLER field is determined by the maximum number tasks that can be run on the system which is limited by the value of /proc/sys/kernel/pid_max as pid values are from 0 to value - 1. This value determines the number of id digits needed by the caller id. The PRINTK_CALLER field is printed as T<id> for a Task Id or C<id> for a CPU Id for a printk in CPU context. The values are left space padded and enclosed in parentheses such as: [ T123] or [ C16] For consistency with dmesg -S which supports the PRINTK_CALLER field the field is printed followed by a space. For JSON format output the PRINTK_CALLER field is identified as caller as that is consistent with it's naming in /dev/kmsg. No space padding is used to reduce space consumed by the JSON output. So the output from the command on a system with PRINTK_CALLER field enabled in the Linux .config file the dmesg output appears as: > dmesg ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -J ... },{ "pri": 6, "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ and > dmesg -J -x ... },{ "fac": "kern", "pri": "info", "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ > For comparison: > dmesg -S ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -S -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub Note: When dmesg uses the old syslog interface the reserved space for the PRINTK_CALLER field is capped at 5 digits because 32-bit kernels are capped at 32768 as the max number of PIDs. However, 64-bit systems are currently capped at 2^22 PIDs (0 - 4194303). The PID cap is set by PID_MAX_LIMIT but the system limit can be less so we use /proc/sys/kernel/pid_max to determine the size needed to hold the maximum PID value size for the current system. Many 64-bit systems support 2^22 PIDs (0 - 4194303) and you see: > dmesg -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [ T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [ T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... > dmesg -S -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... This is the only difference seen with PRINTK_CALLER configured and printing between the dmesg /dev/kmsg interface and the dmesg -S syslog interface. Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Edward Chron <echron@arista.com>

util-linux/sys-utils dmesg add PRINTK_CALLER support Submission to Project: util-linux Open Incident: util-linux#2609 at github.com/util-linux/issues/2609 Component: util-linux/sys-utils File: dmesg.c Code level patch applied against: 2.39.3 - latest code pulled from git.github.com:util-linux/util-linux.git Revision: #1 on 2023/12/08 per Review from Karel Zak Revision: #2 on 2023/12/12 Adjust line offsets for master update and Add caller_id_size init to dmesg -K Revision: #3 on 2023/12/12 Use of sizeof for cidbuf and limit search for caller_id to dmesg prefix to msg text Revision: util-linux#4 on 2023/12/15 Ensure SYSLOG and kmsg inputs have caller_id_size set appropriately Revision: util-linux#5 on 2023/12/24 Make caller_id width consistent with makedumpfile Revision: util-linux#6 on 2023/12/30 Use updated test naming convention Include expected results for new tests Add support to standard dmesg command for the optional Linux Kernel debug CONFIG option PRINTK_CALLER which adds an optional dmesg field that contains the Thread Id or CPU Id that is issuing the printk to add the message to the kernel ring buffer. This makes debugging simpler as dmesg entries for a specific thread or CPU can be recognized. The dmesg -S using the old syslog interface supports printing the PRINTK_CALLER field but currently standard dmesg does not support printing the field if present. There are utilities that use dmesg and so it would be optimal if dmesg supported PRINTK_CALLER as well. The additional field provided by PRINTK_CALLER is only present if it was configured for the Linux kernel where the dmesg command is run. It is a debug option and not configured by default so the dmesg output will only change for those kernels where the option was configured when the kernel was built. For users who went to the trouble to configure PRINTK_CALLER and have the extra field available for debugging, having dmesg print the field is very helpful. Size of the PRINTK_CALLER field is determined by the maximum number tasks that can be run on the system which is limited by the value of /proc/sys/kernel/pid_max as pid values are from 0 to value - 1. This value determines the number of id digits needed by the caller id. The PRINTK_CALLER field is printed as T<id> for a Task Id or C<id> for a CPU Id for a printk in CPU context. The values are left space padded and enclosed in parentheses such as: [ T123] or [ C16] For consistency with dmesg -S which supports the PRINTK_CALLER field the field is printed followed by a space. For JSON format output the PRINTK_CALLER field is identified as caller as that is consistent with it's naming in /dev/kmsg. No space padding is used to reduce space consumed by the JSON output. So the output from the command on a system with PRINTK_CALLER field enabled in the Linux .config file the dmesg output appears as: > dmesg ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -J ... },{ "pri": 6, "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ and > dmesg -J -x ... },{ "fac": "kern", "pri": "info", "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ > For comparison: > dmesg -S ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -S -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub Note: When dmesg uses the old syslog interface the reserved space for the PRINTK_CALLER field is capped at 5 digits because 32-bit kernels are capped at 32768 as the max number of PIDs. However, 64-bit systems are currently capped at 2^22 PIDs (0 - 4194303). The PID cap is set by PID_MAX_LIMIT but the system limit can be less so we use /proc/sys/kernel/pid_max to determine the size needed to hold the maximum PID value size for the current system. Many 64-bit systems support 2^22 PIDs (0 - 4194303) and you see: > dmesg -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [ T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [ T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... > dmesg -S -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... This is the only difference seen with PRINTK_CALLER configured and printing between the dmesg /dev/kmsg interface and the dmesg -S syslog interface. Tests naming has been revised based on naming convention Thomas used to introduce dmest json tests. The naming of test and input files that reside in tests/ts/dmeg include: <name> are existing dmesg syslog interface tests and input files. cid-<name> are dmesg syslog interface caller_id tests and input files. json-<name> are dmesg kmsg interface tests and input files. cid-json-<name> are dmesg kmsg interface caller_id tests and input files. Resulting expected files match the test names. Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Edward Chron <echron@arista.com>

Submission to Project: util-linux Open Incident: util-linux#2609 at github.com/util-linux/issues/2609 Component: util-linux/sys-utils File: dmesg.c Code level patch applied against: 2.39.3 - latest code pulled from git.github.com:util-linux/util-linux.git Revision: #1 on 2023/12/08 per Review from Karel Zak Revision: #2 on 2023/12/12 Adjust line offsets for master update and Add caller_id_size init to dmesg -K Revision: #3 on 2023/12/12 Use of sizeof for cidbuf and limit search for caller_id to dmesg prefix to msg text Revision: util-linux#4 on 2023/12/15 Ensure SYSLOG and kmsg inputs have caller_id_size set appropriately Revision: util-linux#5 on 2023/12/24 Make caller_id width consistent with makedumpfile Revision: util-linux#6 on 2023/12/30 Use updated test naming convention Revision: util-linux#7 on 2024/01/04 Normalize kmsg caller_id spacing for test platforms by removing caller_id padding in test generated output. Add support to standard dmesg command for the optional Linux Kernel debug CONFIG option PRINTK_CALLER which adds an optional dmesg field that contains the Thread Id or CPU Id that is issuing the printk to add the message to the kernel ring buffer. This makes debugging simpler as dmesg entries for a specific thread or CPU can be recognized. The dmesg -S using the old syslog interface supports printing the PRINTK_CALLER field but currently standard dmesg does not support printing the field if present. There are utilities that use dmesg and so it would be optimal if dmesg supported PRINTK_CALLER as well. The additional field provided by PRINTK_CALLER is only present if it was configured for the Linux kernel where the dmesg command is run. It is a debug option and not configured by default so the dmesg output will only change for those kernels where the option was configured when the kernel was built. For users who went to the trouble to configure PRINTK_CALLER and have the extra field available for debugging, having dmesg print the field is very helpful. Size of the PRINTK_CALLER field is determined by the maximum number tasks that can be run on the system which is limited by the value of /proc/sys/kernel/pid_max as pid values are from 0 to value - 1. This value determines the number of id digits needed by the caller id. The PRINTK_CALLER field is printed as T<id> for a Task Id or C<id> for a CPU Id for a printk in CPU context. The values are left space padded and enclosed in parentheses such as: [ T123] or [ C16] For consistency with dmesg -S which supports the PRINTK_CALLER field the field is printed followed by a space. For JSON format output the PRINTK_CALLER field is identified as caller as that is consistent with it's naming in /dev/kmsg. No space padding is used to reduce space consumed by the JSON output. So the output from the command on a system with PRINTK_CALLER field enabled in the Linux .config file the dmesg output appears as: > dmesg ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -J ... },{ "pri": 6, "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ and > dmesg -J -x ... },{ "fac": "kern", "pri": "info", "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ > For comparison: > dmesg -S ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -S -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub Note: When dmesg uses the old syslog interface the reserved space for the PRINTK_CALLER field is capped at 5 digits because 32-bit kernels are capped at 32768 as the max number of PIDs. However, 64-bit systems are currently capped at 2^22 PIDs (0 - 4194303). The PID cap is set by PID_MAX_LIMIT but the system limit can be less so we use /proc/sys/kernel/pid_max to determine the size needed to hold the maximum PID value size for the current system. Many 64-bit systems support 2^22 PIDs (0 - 4194303) and you see: > dmesg -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [ T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [ T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... > dmesg -S -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... This is the only difference seen with PRINTK_CALLER configured and printing between the dmesg /dev/kmsg interface and the dmesg -S syslog interface. Tests naming has been revised based on naming convention Thomas used to introduce dmest json tests. The naming of test and input files that reside in tests/ts/dmeg include: <name> are existing dmesg syslog interface tests and input files. cid-<name> are dmesg syslog interface caller_id tests and input files. json-<name> are dmesg kmsg interface tests and input files. cid-json-<name> are dmesg kmsg interface caller_id tests and input files. Resulting expected files match the test names. Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Edward Chron <echron@arista.com>

Submission to Project: util-linux Open Incident: util-linux#2609 at github.com/util-linux/issues/2609 Component: util-linux/sys-utils File: dmesg.c Code level patch applied against: 2.39.3 - latest code pulled from git.github.com:util-linux/util-linux.git Revision: #1 on 2023/12/08 per Review from Karel Zak Revision: #2 on 2023/12/12 Adjust line offsets for master update and Add caller_id_size init to dmesg -K Revision: #3 on 2023/12/12 Use of sizeof for cidbuf and limit search for caller_id to dmesg prefix to msg text Revision: util-linux#4 on 2023/12/15 Ensure SYSLOG and kmsg inputs have caller_id_size set appropriately Revision: util-linux#5 on 2023/12/24 Make caller_id width consistent with makedumpfile Revision: util-linux#6 on 2023/12/30 Use updated test naming convention Revision: util-linux#7 on 2024/01/04 Normalize kmsg caller_id spacing for test platforms by removing caller_id padding in test generated output. Add support to standard dmesg command for the optional Linux Kernel debug CONFIG option PRINTK_CALLER which adds an optional dmesg field that contains the Thread Id or CPU Id that is issuing the printk to add the message to the kernel ring buffer. This makes debugging simpler as dmesg entries for a specific thread or CPU can be recognized. The dmesg -S using the old syslog interface supports printing the PRINTK_CALLER field but currently standard dmesg does not support printing the field if present. There are utilities that use dmesg and so it would be optimal if dmesg supported PRINTK_CALLER as well. The additional field provided by PRINTK_CALLER is only present if it was configured for the Linux kernel where the dmesg command is run. It is a debug option and not configured by default so the dmesg output will only change for those kernels where the option was configured when the kernel was built. For users who went to the trouble to configure PRINTK_CALLER and have the extra field available for debugging, having dmesg print the field is very helpful. Size of the PRINTK_CALLER field is determined by the maximum number tasks that can be run on the system which is limited by the value of /proc/sys/kernel/pid_max as pid values are from 0 to value - 1. This value determines the number of id digits needed by the caller id. The PRINTK_CALLER field is printed as T<id> for a Task Id or C<id> for a CPU Id for a printk in CPU context. The values are left space padded and enclosed in parentheses such as: [ T123] or [ C16] For consistency with dmesg -S which supports the PRINTK_CALLER field the field is printed followed by a space. For JSON format output the PRINTK_CALLER field is identified as caller as that is consistent with it's naming in /dev/kmsg. No space padding is used to reduce space consumed by the JSON output. So the output from the command on a system with PRINTK_CALLER field enabled in the Linux .config file the dmesg output appears as: > dmesg ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -J ... },{ "pri": 6, "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ and > dmesg -J -x ... },{ "fac": "kern", "pri": "info", "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ > For comparison: > dmesg -S ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -S -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub Note: When dmesg uses the old syslog interface the reserved space for the PRINTK_CALLER field is capped at 5 digits because 32-bit kernels are capped at 32768 as the max number of PIDs. However, 64-bit systems are currently capped at 2^22 PIDs (0 - 4194303). The PID cap is set by PID_MAX_LIMIT but the system limit can be less so we use /proc/sys/kernel/pid_max to determine the size needed to hold the maximum PID value size for the current system. Many 64-bit systems support 2^22 PIDs (0 - 4194303) and you see: > dmesg -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [ T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [ T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... > dmesg -S -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... This is the only difference seen with PRINTK_CALLER configured and printing between the dmesg /dev/kmsg interface and the dmesg -S syslog interface. Tests naming has been revised based on naming convention Thomas used to introduce dmest json tests. The naming of test and input files that reside in tests/ts/dmeg include: <name> are existing dmesg syslog interface tests and input files. cid-<name> are dmesg syslog interface caller_id tests and input files. json-<name> are dmesg kmsg interface tests and input files. cid-json-<name> are dmesg kmsg interface caller_id tests and input files. Resulting expected files match the test names. Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Edward Chron <echron@arista.com> Signed-off-by: Karel Zak <kzak@redhat.com>

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>

Submission to Project: util-linux Open Incident: util-linux#2609 at github.com/util-linux/issues/2609 Component: util-linux/sys-utils File: dmesg.c Code level patch applied against: 2.39.3 - latest code pulled from git.github.com:util-linux/util-linux.git Revision: #1 on 2023/12/08 per Review from Karel Zak Revision: #2 on 2023/12/12 Adjust line offsets for master update and Add caller_id_size init to dmesg -K Revision: util-linux#3 on 2023/12/12 Use of sizeof for cidbuf and limit search for caller_id to dmesg prefix to msg text Revision: util-linux#4 on 2023/12/15 Ensure SYSLOG and kmsg inputs have caller_id_size set appropriately Revision: util-linux#5 on 2023/12/24 Make caller_id width consistent with makedumpfile Revision: util-linux#6 on 2023/12/30 Use updated test naming convention Revision: util-linux#7 on 2024/01/04 Normalize kmsg caller_id spacing for test platforms by removing caller_id padding in test generated output. Add support to standard dmesg command for the optional Linux Kernel debug CONFIG option PRINTK_CALLER which adds an optional dmesg field that contains the Thread Id or CPU Id that is issuing the printk to add the message to the kernel ring buffer. This makes debugging simpler as dmesg entries for a specific thread or CPU can be recognized. The dmesg -S using the old syslog interface supports printing the PRINTK_CALLER field but currently standard dmesg does not support printing the field if present. There are utilities that use dmesg and so it would be optimal if dmesg supported PRINTK_CALLER as well. The additional field provided by PRINTK_CALLER is only present if it was configured for the Linux kernel where the dmesg command is run. It is a debug option and not configured by default so the dmesg output will only change for those kernels where the option was configured when the kernel was built. For users who went to the trouble to configure PRINTK_CALLER and have the extra field available for debugging, having dmesg print the field is very helpful. Size of the PRINTK_CALLER field is determined by the maximum number tasks that can be run on the system which is limited by the value of /proc/sys/kernel/pid_max as pid values are from 0 to value - 1. This value determines the number of id digits needed by the caller id. The PRINTK_CALLER field is printed as T<id> for a Task Id or C<id> for a CPU Id for a printk in CPU context. The values are left space padded and enclosed in parentheses such as: [ T123] or [ C16] For consistency with dmesg -S which supports the PRINTK_CALLER field the field is printed followed by a space. For JSON format output the PRINTK_CALLER field is identified as caller as that is consistent with it's naming in /dev/kmsg. No space padding is used to reduce space consumed by the JSON output. So the output from the command on a system with PRINTK_CALLER field enabled in the Linux .config file the dmesg output appears as: > dmesg ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -J ... },{ "pri": 6, "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ and > dmesg -J -x ... },{ "fac": "kern", "pri": "info", "time": 520.897104, "caller": "T3919", "msg": "usb 3-3: Product: USB 2.0 Hub" },{ > For comparison: > dmesg -S ... [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub and > dmesg -S -x ... kern :info : [ 520.897104] [ T3919] usb 3-3: Product: USB 2.0 Hub Note: When dmesg uses the old syslog interface the reserved space for the PRINTK_CALLER field is capped at 5 digits because 32-bit kernels are capped at 32768 as the max number of PIDs. However, 64-bit systems are currently capped at 2^22 PIDs (0 - 4194303). The PID cap is set by PID_MAX_LIMIT but the system limit can be less so we use /proc/sys/kernel/pid_max to determine the size needed to hold the maximum PID value size for the current system. Many 64-bit systems support 2^22 PIDs (0 - 4194303) and you see: > dmesg -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [ T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [ T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... > dmesg -S -x ... kern :info : [ 520.899558] [ T3919] hub 3-3:1.0: USB hub found ... kern :info : [ 9830.456898] [T98982] cgroup: fork rejected by pids ... kern :info : [14301.158878] [T137336] cgroup: fork rejected by pids ... kern :info : [18980.803190] [T1637865] cgroup: fork rejected by pids ... This is the only difference seen with PRINTK_CALLER configured and printing between the dmesg /dev/kmsg interface and the dmesg -S syslog interface. Tests naming has been revised based on naming convention Thomas used to introduce dmest json tests. The naming of test and input files that reside in tests/ts/dmeg include: <name> are existing dmesg syslog interface tests and input files. cid-<name> are dmesg syslog interface caller_id tests and input files. json-<name> are dmesg kmsg interface tests and input files. cid-json-<name> are dmesg kmsg interface caller_id tests and input files. Resulting expected files match the test names. Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Edward Chron <echron@arista.com> Signed-off-by: Karel Zak <kzak@redhat.com>

karelzak closed this as completed Nov 7, 2012

ht990332 mentioned this issue Feb 25, 2016

lsipc crashes when not ran inside an xsession (gnome) #290

Open

Ataraxiall mentioned this issue Jul 27, 2021

hwclock Timed out waiting for time change Error #1387

Closed

HenrikBach1 added a commit to HenrikBach1/util-linux that referenced this issue Jan 16, 2022

Write output of option command (util-linux#3)

3e0d6f4

masatake mentioned this issue Apr 3, 2022

tests: (lsfd) add missing dup2 calls to assign proper file descriptors #1639

Merged

rscottha mentioned this issue Mar 19, 2023

/usr/bin/login core dumps #2121

Closed

rpigott mentioned this issue Mar 23, 2023

hexdump-parse: handle truncated format pattern #2133

Merged

t-8ch mentioned this issue Nov 20, 2023

lsfd: avoid undefined behavior #2586

Merged

karelzak mentioned this issue Dec 13, 2023

dmesg: add PRINTK_CALLER support #2647

Merged

egchron mentioned this issue Dec 18, 2023

Add support to standard dmesg command for the optional Linux Kernel debug CONFIG option PRINTK_CALLER field #2609

Open

This was referenced Feb 25, 2024

hexdump hang when reading format file with --format-file #2805

Open

Heap Buffer Overflow in Hexdump when processing format files #2806

Closed

Multiple memory corruption problems in dmesg #2807

Closed

biubiuzy mentioned this issue Mar 18, 2024

last: avoid out of bounds array access #2843

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fdisk: build fails on IA32 architectures #3

fdisk: build fails on IA32 architectures #3

morfoh commented Feb 15, 2012

karelzak commented Nov 7, 2012

fdisk: build fails on IA32 architectures #3

fdisk: build fails on IA32 architectures #3

Comments

morfoh commented Feb 15, 2012

fdisk fails for for all tested arch/cpu types emitting following error:

make[2]: *** [fdisk-fdiskbsdlabel.o] Error 1

karelzak commented Nov 7, 2012