As a follow-up to my initial post ... Obviously, changing the return statement in setmetamode.c is only a "band-aid" that restores operation, but does nothing to correct the underlying problem.
Upon closer examination, it appears that the KDGKBMETA IOCTL that is called by setmetamode.c, is subsequently calling: put_user (<unsigned int>, (int __user*) arg); Unfortunately, the argument (ometa) is only declared as "char" in setmetamode.c. So, in essence, we are asking the kernel to store an <unsigned int> into a user space location that has only been allocated as a "char". I now believe that the appropriate correction is to change the "char ometa, nmeta;" declaration in setmetamode.c to "unsigned int ometa, nmeta;". During my testing, this change eliminated the StackSmashing detection and subsequent traceback. If this problem and analysis is confirmed by other users, I would hope that this fix could be propagated into a subsequent Stretch update so as to restore operation of the setmetamode utility.