mmap crash on Windows with out of range file descriptor

[briancurtin]

BPO	8105
Nosy	@birkenfeld, @briancurtin
Files	mmap_crash.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/briancurtin'
closed_at = <Date 2010-08-01.15:50:08.931>
created_at = <Date 2010-03-10.00:42:24.613>
labels = ['extension-modules', 'OS-windows', 'type-crash']
title = 'mmap crash on Windows with out of range file descriptor'
updated_at = <Date 2010-08-01.15:50:08.929>
user = 'https://github.com/briancurtin'

bugs.python.org fields:

activity = <Date 2010-08-01.15:50:08.929>
actor = 'brian.curtin'
assignee = 'brian.curtin'
closed = True
closed_date = <Date 2010-08-01.15:50:08.931>
closer = 'brian.curtin'
components = ['Extension Modules', 'Windows']
creation = <Date 2010-03-10.00:42:24.613>
creator = 'brian.curtin'
dependencies = []
files = ['16516']
hgrepos = []
issue_num = 8105
keywords = ['patch']
message_count = 4.0
messages = ['100774', '100775', '112278', '112347']
nosy_count = 2.0
nosy_names = ['georg.brandl', 'brian.curtin']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue8105'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']

[briancurtin]

Creating an mmap object can crash the interpreter on Windows if a file descriptor is passed in which is outside of the range for _get_osfhandle. I noticed the crash possibility while reviewing the Modules/mmapmodule.c code for work on another issue related to the consistency of the exceptions which mmap raises.

This can be tested by creating a mmap object with the file descriptor for a socket. This is not a valid way to create an mmap, but it represents a valid file descriptor which is out of range. For example, I created a socket with a file descriptor of 124, and _get_osfhandle expects the descriptor to be between 0 and 23.

Patch against trunk, with a test.

Note that this does not seem to affect 2.6 (not sure why, yet).

[briancurtin]

I should add that I tried the same thing on linux and no crash occured, it properly raised an exception.

[birkenfeld]

What's the status here? Can it be committed?

[briancurtin]

Fixed in r83407 (py3k), r83409 (release31-maint), and r83410 (release27-maint).