|
Bugzilla – Full Text Bug Listing |
| Summary: | xentop fails with long interface name | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Dion Kant <g.w.kant> |
| Component: | Xen | Assignee: | Xen Virtualization <xen-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | carnold, g.w.kant |
| Version: | Leap 15.5 | Flags: | jbeulich:
needinfo?
(g.w.kant) |
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Leap 15.5 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | possible fix | ||
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. |
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.