bin/45856: csh(1) becomes very hungry when trying to handle a certain type of string

["Bernhard Riedel" <bernhard%sdg.de@localhost>]

>Number:         45856
>Category:       bin
>Synopsis:       csh consuming a preposterous amount of resources when trying 
>to digest a string
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 19 01:50:00 +0000 2012
>Originator:     Bernhard "Burnhard" Riedel
>Release:        NetBSD 5.1
>Organization:
a nice concept
>Environment:
System: NetBSD wip.crg.de 5.1 NetBSD 5.1 (WIP) #0: Sun Nov 27 22:39:05 CET 2011 
root%wip.crg.de@localhost:/sdata/usr/src/sys/arch/amd64/compile/WIP amd64
Architecture: x86_64
Machine: amd64
>Description:

When csh tries to parse or output certain strings, it will require an
 unexpected amount of resources, especially memory.
It will eventually fail with "Out of memory.", without lasting
 effects (apart from other processes having to be paged in again).
The affected system might become virtually unusable for a few minutes.
In some cases, the misbehaving csh can only be terminated with kill -9.
The problem was repeated with various locale settings and with csh inside 
uxterm,
 xterm, hanterm and rxvt (all NetBSD-5.1/amd64) and wscons console (5.1.1/i386)
Fellow NetBSD users on IRCnet and freenode helped to confirm and reproduce the
 bug, it seems to be limited to NetBSD and OpenBSD.


>How-To-Repeat:

printf "\x22\x22\xec\xb6\x94\xea\xb0\x80\x20\xec\x88\x99\xec\xa0\x9c\x0a" | csh

Or, in a csh:

set blah = `printf 
"\x22\x22\xec\xb6\x94\xea\xb0\x80\x20\xec\x88\x99\xec\xa0\x9c\x0a"`

echo $blah
  or
printf $blah
  or
set blu = $blah
  or
mkdir $blah
  or just
$blah

The string above consists of two doublequotes, followed by two words in
 (utf-8-encoded) Korean, 2 syllables each, separated by space.

There are many other strings having the same effect, e.g. 
"\xec\xb6\x94\xea\xb0\x80\x5c\x20\xec\x88\x99\xec\xa0\x9c\x0a" which shows that 
the artificial looking pair of doublequotes isn't necessary.
Originally, I encountered that bug while using midnight commander,
 with quite a few really existing filenames on my system.

>Fix:

Unknown so far.