gh-128049: Fix type confusion bug with the return value of a custom ExceptionGroup split function

Lib/test/test_exception_group.py

@@ -576,6 +576,20 @@ def test_iteration_full_tracebacks(self):
                 expected_tbs[i])
 
 
+class CustomExceptionGroupSplitTest(ExceptionGroupTestBase):
+    # See https://github.com/python/cpython/issues/128049
+    def test_invalid_split_return_value(self):
+        class Evil(BaseExceptionGroup):
+            def split(self, types):
+                return "NOT A TUPLE"
+
+        with self.assertRaises(TypeError):
+            try:
+                raise Evil("message here", [Exception()])
+            except* Exception:
+                pass
+
+
 class ExceptionGroupSplitTestBase(ExceptionGroupTestBase):
 
     def split_exception_group(self, eg, types):

Misc/NEWS.d/next/Core_and_Builtins/2024-12-18-14-22-48.gh-issue-128079.SUD5le.rst

@@ -0,0 +1,3 @@
+Fixed a type confusion bug where the caller of an :class:`ExceptionGroup`
+object's :meth:`~BaseExceptionGroup.split` function had improper checks
+implemented leading to any return value being interpreted as a tuple.

Python/ceval.c

@@ -2095,8 +2095,15 @@ _PyEval_ExceptionGroupMatch(PyObject* exc_value, PyObject *match_type,
         if (pair == NULL) {
             return -1;
         }
-        assert(PyTuple_CheckExact(pair));
-        assert(PyTuple_GET_SIZE(pair) == 2);
+
+        if (!PyTuple_CheckExact(pair) || PyTuple_Size(pair) != 2) {
+            PyErr_Format(PyExc_TypeError,
+                        "%s.split must return a 2-tuple",
+                        Py_TYPE(exc_value)->tp_name);
+            Py_DECREF(pair);
+            return -1;
+        }
+
         *match = Py_NewRef(PyTuple_GET_ITEM(pair, 0));
         *rest = Py_NewRef(PyTuple_GET_ITEM(pair, 1));
         Py_DECREF(pair);