There is a typo in the radix tree obmalloc code, spotted by Inada Naoki. 

-#define MAP_TOP_MASK (MAP_BOT_LENGTH - 1)
+#define MAP_TOP_MASK (MAP_TOP_LENGTH - 1)

This should be fixed both in the main branch and in 3.10.x.

When I am trying to understand this issue, I see this segfault.

https://gist.github.com/methane/1b83e2abc6739017e0490c5f70a27b52

I am not sure this segfault is caused by this issue or not. If this is unrelated, I will create another issue.

I have not yet been able to reproduce methane's crash.  My guess it it's not related.

An explanation of what I think the impact of this bug is:

The radix tree is used to determine if memory is from obmalloc or from the system malloc (i.e return value from address_in_range()).  WIth ADDRESS_BITS set to 48, we ignore the top 16 bits of addresses.  The next 10 bits are supposed to be the index into the top level node array for the radix tree.  Due to the bug, we mask those and only use the bottom 8 of those 10.  So, if you have virtual addresses that span more than that 8 bit range, we will index into the wrong node.  That means address_in_range() could give the wrong answer.  Which means you might try to free memory with the wrong malloc.

I think this is likely to be triggered only if you allocate a massive amount of memory, like 70 TB.  However, triggering it would depend on how the kernel maps virtual memory to the Python process.  I.e. there might be a wierd OS that gives pages at 0x7f0000000000 and then right after pages at 0x3f0000000000.

New changeset 311910b31a4bd94dc79298388b7cb65ca5546438 by Neil Schemenauer in branch 'main':
bpo-45521: Fix a bug in the obmalloc radix tree code. (GH-29051)
https://github.com/python/cpython/commit/311910b31a4bd94dc79298388b7cb65ca5546438

New changeset 1cdac61065e72db60d26e03ef9286d2743d7000e by Miss Islington (bot) in branch '3.10':
bpo-45521: Fix a bug in the obmalloc radix tree code. (GH-29051) (GH-29122)
https://github.com/python/cpython/commit/1cdac61065e72db60d26e03ef9286d2743d7000e