This crash is surprisingly consistent across versions, operating
systems, and whether the c module is used or not:

Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.cElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.5.4 (r254:67916, Jun  3 2009, 14:22:10) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.4.4 (#2, Oct 22 2008, 20:20:22) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from elementtree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.5 (release25-maint, Jul 23 2008, 18:15:29) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import fromstring
>>> fromstring('<?xml \xcb\x8c ?>')
Segmentation fault

I'm a little fuzzy on who's responsible for elementtree, so if there's a
more appropriate venue to file this bug, please let me know.

Confirmed on 3.1 on Windows too.

I'm seeing this on the built-in python on os x 10.6, too:
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin


But neither with the trunk
Python 2.7a0 (trunk:75433M, Oct 15 2009, 08:27:13) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

nor with a ports installation
Python 2.6.3 (r263:75183, Oct  7 2009, 07:05:03) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

Here is a stacktrace of the crash with the system Python 2.6.1 on Mac OS
X 10.6.1:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000101000000
0x00007fff810f96b8 in XML_SetEncoding ()
(gdb) bt
#0  0x00007fff810f96b8 in XML_SetEncoding ()
#1  0x00007fff810ecad0 in XML_GetCurrentLineNumber ()
#2  0x00000001005c2150 in initpyexpat ()
#3  0x00000001005c3516 in initpyexpat ()
#4  0x00000001000891df in PyEval_EvalFrameEx ()
#5  0x0000000100089330 in PyEval_EvalFrameEx ()
#6  0x0000000100089330 in PyEval_EvalFrameEx ()
#7  0x000000010008accf in PyEval_EvalCodeEx ()
#8  0x000000010008ad62 in PyEval_EvalCode ()
#9  0x00000001000a265a in Py_CompileString ()
#10 0x00000001000a44dd in PyRun_InteractiveOneFlags ()
#11 0x00000001000a4615 in PyRun_InteractiveLoopFlags ()
#12 0x00000001000a4685 in PyRun_AnyFileExFlags ()
#13 0x00000001000b0286 in Py_Main ()
#14 0x0000000100000e6c in ?? ()

This has already been fixed with r74429, but no issue was filed at the time.

It should be backported to 2.6 and 3.1 at least.
And probably to 2.5 as well, because a crash on XML input can be
considered as a security issue.

Raising to "deferred blocker" so that it does not block 2.6.4.

Is our copy of expat in sync with upstream? How does maintenance happen?

The same thing had been discovered in expat 12 months before:
http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmltok_impl.c?r1=1.13&r2=1.15
But expat hasn't made any release since 2.0.1, in June 2007...

Are you suggesting to update our copy of expat with its latest cvs revision?

I don't know really. I wonder how Linux distributions handle maintenance
of that library.
Perhaps Fred Drake can help us?

FWIW, the latest Debian package: http://packages.debian.org/sid/libexpat1
is also vulnerable (I checked in the sources expat_2.0.1.orig.tar.gz,
and it's not corrected in expat_2.0.1-4.diff.tgz)

Adding 2.5 back, looks like it was removed accidentally.

Also, here's a list of strings for testing purposes: 

['<?xml \xee\xae\x94 ?>', '<?xml \xc4\x9d ?>', '<?xml \xc8\x84 ?>',
'<?xml \xd9\xb5 ?>', '<?xml \xd9\xaa ?>', '<?xml \xc9\x88 ?>', '<?xml
\xcb\x8c ?>']

This was merged into 2.6 with r74432, into 2.5 with r77666, into 3.1 with r74436.