gh-143005: prevent incompatible __class__ reassignment for ctypes arrays

[VanshAgarwal24036]

This PR fixes a heap buffer overflow in ctypes arrays caused by assigning
class to an incompatible array type.

The change rejects class reassignment when the new array type differs
in length, size, or element type, preventing out-of-bounds memory access.
A regression test is included.

• Issue: Heap buffer overflow in ctypes array assignment via __class__ swap #143005

[VanshAgarwal24036]

@serhiy-storchaka
I’ve opened a PR fixing the ctypes array class reassignment issue discussed here.
CI is green now; no rush, just sharing in case you have time to take a look.

[serhiy-storchaka]

Thank you for your PR, @VanshAgarwal24036. I did not know what to do with this issue. It seems that adding check in tp_setattro is the way to go. But I suspect we need more tests -- each condition should be covered by alternate tests,

[picnixz]

What if we simply expose __class__ as a getset? isn't it possible?

[serhiy-storchaka]

There are problems with such special names. If we expose __class__ as a getset, then c_long.__class__ will be not a type of c_long (the same as type(c_long)), but a descriptor. This will confuse much code.

[picnixz]

Arf yes you are right. It just feels to me that it is an overkill but I do not think we have a better alternative, do we?

[VanshAgarwal24036]

Thanks for the discussion

I agree exposing __class__ as getset would be problematic since it would turn
type(obj).__class__ into descriptor and break expectations.

Given that validating reassignment in tp_setattro seems like least disruptive
approach. I will follow up with additional tests to cover the remaining edge cases
(abstract targets, non-array targets, zero-length arrays, etc.) if you suggest.

[VanshAgarwal24036]

@serhiy-storchaka Do i add more test case as we discuss or how to proceed?

[serhiy-storchaka]

Are there tests for old_info == NULL, new_info == NULL, old_info->length < 0, new_info->length < 0? Add tests for successful __class__ assignments. For example, c_int, c_long and c_longlong should be compatible if they have the same size (and ssize_t should be compatible with one of them). Are c_long and c_ulong compatible? What about arrays of structures? Arrays of pointers of different type?

Since there are changes in from_param(), tests for from_param() are also needed.

[VanshAgarwal24036]

@serhiy-storchaka Please review it

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[serhiy-storchaka]

Please add a test for deletion of the __class__ attribute (it crashes now) and fix it.

The following cases are not covered by tests:

• old_info == NULL
• old_info->length < 0
• new_info->length < 0

Is this possible to test? Are these cases possible in theory?

Also, all tests with different lengths have also different sizes, and all tests with different sizes have different lengths. We need tests for different sizes and same length and for different lengths with same size.

[serhiy-storchaka]

c_long and c_ulonglong can also have different size. Should not we test c_long with c_longlong.

[serhiy-storchaka]

c_int and c_double most likely have different size. We need to test different types with the same size. I suggest to unite multiple tests in the same method and use a loop with an array of type pairs:

for A, B in [
    (c_int * 3, c_double * 3),
    (c_long * 3, c_double * 3),
    (c_longlong * 3, c_double * 3),
    ...
]:
    with self.subTest(A=A, B=B):
        a = A()
        with self.assertRaises(TypeError):
            a.__class__ = B

You can also use test.support.subTests.

[serhiy-storchaka]

If sizeof(c_int) != sizeof(c_long), try other pair, for example c_long and c_longlong.

[serhiy-storchaka]

Does it work for different structs with the same definition?