zstream: build with debug to fix stack overruns

[robn]

[Sponsors: Klara, Inc., Wasabi Technology, Inc.]

Motivation and Context

Production builds of zstream decompress can smash the stack. In the best case, it crashes. In the worst it writes garbage into the stream.

See #16476. This PR is the easy fix; the real problem runs deeper.

Description

abd_t differs in size depending on whether or not ZFS_DEBUG is set. It turns out that libzpool is built with FORCEDEBUG_CPPFLAGS, which sets -DZFS_DEBUG, and so it always has a larger abd_t with extra debug fields, regardless of whether or not --enable-debug is set.

zdb, ztest and zhack are also all built with FORCEDEBUG_CPPFLAGS, so had the same idea of the size of abd_t, but zstream was not, and used the "smaller" abd_t. In practice this didn't matter because it never used abd_t directly.

This changed in b4d81b1, zstream was switched to use stack ABDs for compression. When built with --enable-debug, zstream implicitly gets ZFS_DEBUG, and everything was fine. Productions builds without that flag ends up with the smaller abd_t, which is now mismatched with libzpool, and causes stack overruns in zstream recompress.

The simplest fix for now is to compile zstream with FORCEDEBUG_CPPFLAGS like the other binaries. This commit does that.

How Has This Been Tested?

@rincebrain actually saw it blow up, and told me about it. My eyeball check is just checking the size of abd_t before and after:

$ for x in zdb ztest zhack zstream ; do libtool --mode=execute gdb --batch --eval-command='print sizeof(abd_t)' $x ; done
$1 = 232
$1 = 232
$1 = 232
$1 = 96

vs

$ for x in zdb ztest zhack zstream ; do libtool --mode=execute gdb --batch --eval-command='print sizeof(abd_t)' $x ; done
$1 = 232
$1 = 232
$1 = 232
$1 = 232

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.