In Python 2.5.4 built from unmodified source:

showard@showardlt:~/src/Python-2.5.4$ ./python
Python 2.5.4 (r254:67916, Jan  7 2009, 20:28:41) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()
>>> p.ParseFile(f)
Segmentation fault

The error is in the control flow in xmlparse_ParseFile()
(Modules/pyexpat.c:1000).  When passed a real file object that's been
closed, PyFile_Check() returns true, but then PyFile_AsFile() returns 0
(since f_fp on the file object is set to zero when the file is closed).
 So the local 'fp' is set to 0, and 'readmethod' is left as NULL.  The
conditional at 1033 then fails, and the call to readinst() at 1041
passes readmethod=NULL, leading eventually to a segfault in
PyObject_Call at Objects/abstract.c:1860.

I think it's present in 2.6 as well, but I'm not sure.  It seems to have
been fixed by chance in 3.0 because Guido removed the first branch in
xmlparse_ParseFile altogether in an unrelated change a while ago.

The attached patch simply checks for fp == 0 and raises an exception.  I
don't know if it's the proper solution but you get the idea.

Built with the attached patch:

showard@showardlt:~/src/Python-2.5.4$ ./python
Python 2.5.4 (r254:67916, Jan  7 2009, 20:28:41) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()   
>>> p.ParseFile(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: attempting to parse closed file

It seems that this is ok in py3k in which case it could be backported to 2.7, or has this already been done?

I double checked this today. On my linux box with 2.6.6 the commands given did cause a segfault. On my windows VM with 2.7.1 it also created a segfault. And to back up Mark's claim, it did not segfault on my 3.1.2 linux install.

I concur. Attaching a refreshed patch (against current 2.7 branch) along with a unittest.

Modified patch to remove PyErr_SetString() as it doesn't do anything. Patch looks good to me otherwise and ran without issue.

You mean, PyErr_Clear()?

Yes I did. Sorry.

Elsewhere, Guido said that this appears *not* to be a security bug since the crash is "triggered by a logic bug in the user's code, not by bad data." Hence, not eligible for backport to 2.5/6, which are in security-fix only mode.

See also #9292.

FWIW I tried to backport 825041fc8e2c and test_pyexpat runs without problem.
The snippet of code in msg79398 now raises a ValueError:
>>> from xml.parsers import expat
>>> f=open('/tmp/foo')
>>> p=expat.ParserCreate()
>>> f.close()
>>> p.ParseFile(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file

The attached patch combines the changes done to pyexpat in 825041fc8e2c (http://hg.python.org/cpython/diff/825041fc8e2c/Modules/pyexpat.c), the cleanup of c52f5df50448 and the tests of issue4877.patch.
The tests segfault without the changes on pyexpat, and pass once they are applied.

New changeset 28705a7987c5 by Ezio Melotti in branch '2.7':
#4877: Fix a segfault in xml.parsers.expat while attempting to parse a closed file.
http://hg.python.org/cpython/rev/28705a7987c5

This is now fixed in 2.7, I also removed the unnecessary call to PyErr_Clear in ba699cf9bdbb (2.7), 6b4467e71872 (3.2), and 2d1d9759d3a4 (3.3).