On Mon, 30 Sep 2024, Dave Jones wrote: > This is a bit of a tricky one. With regard to the first patch > (fortify2.patch), while it's expedient, I really don't like the idea of > just turning down the FORTIFY_SOURCE option, so I'm afraid I can't > sponsor that one.
The fortify2.patch was only a first workaround for this issue (to get xymon online). It is superseded by 100_md5_bufferoverflow.patch, which solves the root cause. > One thing that does concern me is that upstream have apparently had a > good tidy-up of their buffer handling code > (https://sourceforge.net/p/xymon/code/8123/), but that this change > doesn't appear there. To be fair, most of their changes seem either > mechanical (ensuring buffer termination after certain operations) or > cosmetic, while this proposed change is neither. The above SVN commit is only part of the 4.x-alpha version, which is not yet released, neither upstream nor in Debian (but there we have an experimental branch, where we try to prepare a release for 4.x): https://salsa.debian.org/debian/xymon/-/tree/experimental > Still, we generally prefer patches are forwarded upstream so we > don't have to maintain them as an Ubuntu delta long term. Could > Roland forward the patch upstream? I developed the patch based on an request on upstream mailing list. I also sent my patch to this list. Sadly the list archive currently is broken (since the migration of the list server from mailman2 to mailman3 on a different server in July 2024). As soon as the archive reappears, I'll ad a link to my patch. > (I note Roland is one of the Debian maintainers of the package, so > presumably it doesn't need forwarding to himself there :) I applied the patch to the Debian git repo, but didn't yet push a release (should do so...). > 1. I'll target this bug to noble and jammy (and oracular implicitly). > Although jammy doesn't *appear* affected here, it presumably *is* but > it's not noticing the buffer overrun because FORTIFY_SOURCE is lower > there. ACK. > 2. Because we don't appear certain that this patch is indeed the root > cause, I'm going to prep a PPA (ppa:waveform/xymon) with builds for > oracular, noble, and jammy, containing the second patch here > (100_md5_bufferoverflow.patch). Could I ask those interested to try the > following and report back if it appears to fix things? For the records: I did some testing on Debian 12 (by defaults using fortify_source=2) and Ubuntu 24.04 (using fortify_source=3 by default) with switching fortify_source=2/3 and as soon as this is set to 3 the software fails (on both OS). The resulting coredumps of xymond_client, xymond_rrd and xymond_alert all pointed to md5hash from lig/digest.c:44. So I checked/patched this code and after this xymon works with fortify_source=3 on all of my systems without segfaulting. Greetings Roland -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2078638 Title: coredumps with Xymon on 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xymon/+bug/2078638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
