bin/56874: /usr/sbin/ipftest frequently dumps core due to uninitialized variable

[tgl%sss.pgh.pa.us@localhost]

>Number:         56874
>Category:       bin
>Synopsis:       /usr/sbin/ipftest frequently dumps core due to uninitialized variable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 09 22:40:00 +0000 2022
>Originator:     Tom Lane
>Release:        HEAD/202206081310Z
>Organization:
PostgreSQL Global Development Group
>Environment:
NetBSD sss2.sss.pgh.pa.us 9.99.97 NetBSD 9.99.97 (SD0) #3: Thu Jun  9 15:19:02 EDT 2022  tgl%nuc1.sss.pgh.pa.us@localhost:/home/tgl/netbsd-H-202206081310Z/obj.hppa/sys/arch/hppa/compile/SD0 hppa
>Description:
I noticed that a lot of the /usr/tests/ipf tests fail on my HPPA box due to core dumps in ipftest.  A bit of debugging found that these were SIGSEGVs caused by following garbage pointers in the "mb_t mb" struct that's a local in main().  The tests are completely clean after the attached quick-hack fix.  I speculate that the program appears to work on other arches because their stacks tend to start out all-zero; but this ain't so on HPPA (and I doubt it's considered guaranteed anywhere).

>How-To-Repeat:
Run ipf tests using atf-run, on a platform that doesn't pre-zero the stack.

>Fix:
Zeroing the "mb" variable like this fixes it for me:

Index: external/bsd/ipf/dist/tools/ipftest.c
===================================================================
RCS file: /cvsroot/src/external/bsd/ipf/dist/tools/ipftest.c,v
retrieving revision 1.4
diff -u -r1.4 ipftest.c
--- external/bsd/ipf/dist/tools/ipftest.c       4 Feb 2018 08:19:42 -0000       1.4
+++ external/bsd/ipf/dist/tools/ipftest.c       9 Jun 2022 22:18:55 -0000
@@ -88,6 +88,7 @@
        ip_t    *ip;
 
        m = &mb;
+       memset(m, 0, sizeof(*m));
        dir = 0;
        dump = 0;
        hlen = 0;


This is kind of an ugly fix --- it seems like there should be someplace else in the program that's responsible for initializing mb_t structs to a valid state.  I did not see a better candidate in a cursory look, though.