Bugzilla – Bug 1212684
xentop fails with long interface name
Last modified: 2023-12-15 18:11:50 UTC
Having an interface defined in the system with a longer name like vlan1000 makes xentop fail with the following message: dom0-2:~ # xentop *** buffer overflow detected ***: terminated Aborted (core dumped) I tracked this down using gdb showing a back trace (gdb) bt #0 0x00007ffff7862c6b in raise () from /lib64/libc.so.6 #1 0x00007ffff7864305 in abort () from /lib64/libc.so.6 #2 0x00007ffff78a8a97 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff7940812 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007ffff793ec40 in __chk_fail () from /lib64/libc.so.6 #5 0x00007ffff793e3c2 in __strcpy_chk () from /lib64/libc.so.6 #6 0x00007ffff7fb3adb in strcpy (__src=<optimized out>, __dest=0x7fffffff6a00 "") at /usr/include/bits/string_fortified.h:90 #7 parseNetDevLine (rxFifo=0x0, rxFrames=0x0, rxComp=0x0, rxMcast=0x0, txFifo=0x0, txColls=0x0, txCarrier=0x0, txComp=0x0, txDrops=<synthetic pointer>, txErrs=<synthetic pointer>, txPackets=<synthetic pointer>, txBytes=<synthetic pointer>, rxDrops=<synthetic pointer>, rxErrs=<synthetic pointer>, rxPackets=<synthetic pointer>, rxBytes=<synthetic pointer>, iface=0x7fffffff6a00 "", line=0x7fffffff6a40 "vlan1000: 741038188 1521283 0 0 0 0 0 0 292284847 1305567 0 0 0 0 0 0\n") at xenstat_linux.c:233 #8 xenstat_collect_networks (node=0x555555584550) at xenstat_linux.c:322 #9 0x00007ffff7fb22d1 in xenstat_get_node (handle=<optimized out>, flags=15) at xenstat.c:245 #10 0x00005555555589f4 in ?? () #11 0x0000555555557337 in ?? () #12 0x00007ffff784d24d in __libc_start_main () from /lib64/libc.so.6 #13 0x000055555555772a in ?? () and finally fixed the problem by increasing the string lengths in xen-4.17.1-testing/tools/libs/stat/xenstat_linux.c function int xenstat_collect_networks(xenstat_node * node) like so: --- xen-4.17.1-orig/tools/libs/stat/xenstat_linux.c 2023-05-02 14:13:40.000000000 +0200 +++ xen-4.17.1-testing/tools/libs/stat/xenstat_linux.c 2023-06-25 13:28:19.328212646 +0200 @@ -272,7 +272,7 @@ { /* Helper variables for parseNetDevLine() function defined above */ int i; - char line[512] = { 0 }, iface[16] = { 0 }, devBridge[16] = { 0 }, devNoBridge[17] = { 0 }; + char line[512] = { 0 }, iface[24] = { 0 }, devBridge[24] = { 0 }, devNoBridge[24] = { 0 }; unsigned long long rxBytes, rxPackets, rxErrs, rxDrops, txBytes, txPackets, txErrs, txDrops; I think naming VLAN device vlan1000 for VLAN 1000 is not to strange and should be handled okay. Not sure though why a string of 16 turns out to be too short but I figured out that extending this with 8 bytes did the job.
String handling in C. Who gets it right in the first attempt? Thank you for the suggested patch. I'm sure parseNetDevLine() must be rewritten from scratch...
Created attachment 868125 [details] possible fix Would you mind giving this patch a try instead?
A fix for this bug is being tested by QA and will be released in the next maintenance update for SLE15-SP5/Leap 5.5 Closing as fixed.
SUSE-SU-2023:3447-1: An update that solves three vulnerabilities and has two fixes can now be installed. Category: security (moderate) Bug References: 1027519, 1212684, 1213616, 1214082, 1214083 CVE References: CVE-2022-40982, CVE-2023-20569, CVE-2023-20593 Sources used: Server Applications Module 15-SP5 (src): xen-4.17.2_02-150500.3.6.1 openSUSE Leap 15.5 (src): xen-4.17.2_02-150500.3.6.1 Basesystem Module 15-SP5 (src): xen-4.17.2_02-150500.3.6.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.