cannot marshal objects with more than 2**31 elements

[mdickinson]

BPO	5308
Nosy	@rhettinger, @mdickinson, @pitrou, @tiran, @skrah, @ericsnowcurrently, @serhiy-storchaka
Files	marshal_overflow.patch: Patch for 3.x marshal_overflow-2.7.patch: Patch for 2.7 marshal_string_leak.patch

^{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/serhiy-storchaka'
closed_at = <Date 2013-07-14.12:39:32.320>
created_at = <Date 2009-02-18.22:45:03.442>
labels = ['interpreter-core', 'type-bug']
title = 'cannot marshal objects with more than 2**31 elements'
updated_at = <Date 2013-07-14.12:39:32.320>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2013-07-14.12:39:32.320>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2013-07-14.12:39:32.320>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2009-02-18.22:45:03.442>
creator = 'mark.dickinson'
dependencies = []
files = ['28977', '28978', '30741']
hgrepos = []
issue_num = 5308
keywords = ['patch']
message_count = 22.0
messages = ['82437', '82440', '82570', '82583', '181535', '181536', '181537', '181554', '181560', '181561', '181562', '181564', '181570', '181572', '181573', '181574', '182011', '182014', '182015', '192093', '192131', '192878']
nosy_count = 8.0
nosy_names = ['rhettinger', 'mark.dickinson', 'pitrou', 'christian.heimes', 'skrah', 'python-dev', 'eric.snow', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue5308'
versions = ['Python 2.7', 'Python 3.3', 'Python 3.4']

[mdickinson]

Two closely related issues in Python/marshal.c, involving writing and
reading of variable-length objects (lists, strings, long integers, ...)

(1) The w_object function in marshal contains many instances of code
like the following:

else if (PyList_CheckExact(v)) {
	w_byte(TYPE_LIST, p);
	n = PyList_GET_SIZE(v);
	w_long((long)n, p);
	for (i = 0; i < n; i++) {
		w_object(PyList_GET_ITEM(v, i), p);
	}
}

On a 64-bit platform there's potential loss of information here
either in the cast "(long)n" (if sizeof(long) is 4), or in
w_long itself (if sizeof(long) is 8). Note that w_long, despite
its name, always writes exactly 4 bytes.

There should at least be an exception raised here if n is not
in the range [-2**31, 2**31). This would make marshalling of
large objects illegal (rather than just wrong).

A more involved fix would allow marshalling of objects of size >= 2**31.
This would obviously involve changing the marshal format, and would make
it impossible to marshal a large object on a 64-bit platform and then
unmarshal it on a 32-bit platform. The latter may not really be a
problem, since memory considerations ought to rule that out anyway.

(2) In r_object (and possibly elsewhere) there are corresponding checks
of the form:

case TYPE_LIST:
	n = r_long(p);
	if (n < 0 || n > INT_MAX) {
		PyErr_SetString(PyExc_ValueError, "bad marshal data");
		retval = NULL;
		break;
	}

...

if we allow marshalling of objects with more than 2**31-1 elements then
these error checks can be relaxed. (And as a matter of principle,
INT_MAX isn't really right here: an int might be only 16 bits long on
some strange platforms...).

[rhettinger]

Given that marshal is primarily about supporting pyc files, do we care?

[mdickinson]

It wouldn't hurt to add the overflow checks though, would it?

[rhettinger]

Why not. Besides it ought to be fun to write the test case for this one :-)

[serhiy-storchaka]

Here is a patch for 3.x which adds checks for size overflow (only on 64-bit platform).

[serhiy-storchaka]

And here is a patch for 2.7.

[serhiy-storchaka]

(And as a matter of principle,
INT_MAX isn't really right here: an int might be only 16 bits long on
 some strange platforms...).

AFAIK Python doesn't support such platforms (and C standard requites at least 32-bit ints). However there are strange platforms with 64-bit ints. That's why I used the explicit constant 0x7FFFFFFF.

[pitrou]

Perhaps you could add a bigmem test for this?
(assuming you have enough memory somewhere to test it)

[mdickinson]

(and C standard requites at least 32-bit ints)

No, that's not true: see Annex E of the standard, where the minimum for INT_MAX is declared to be 32767.

[skrah]

Theoretically int may be 16 bits (C99):

5.2.4.2.1 Sizes of integer types <limits.h>

-- maximum value for an object of type int
INT_MAX +32767 // 2**15 − 1

I agree that Python wouldn't compile on such a platform anyway.

[skrah]

Hmm, Mark was faster. ;)