lib: fix a Null Pointer Dereference bug.

[mugitya03]

The function elfsect_wrap can return a NULL value when allocation fails at line 573.

	w = (struct elfsect *)typeobj_elfsect.tp_alloc(&typeobj_elfsect, 0);
	if (!w)
		return NULL;

The null value returned by function elfsect_wrap is saved to w->sects[idx] and further assigned to pointer ret. Then the pointer ptr is passed to function Py_INCREF at line , where it can be dereferenced.

		w->sects[idx] = elfsect_wrap(w, scn, idx, name);
	}

	ret = w->sects[idx];
	Py_INCREF(ret);
	return ret;

The definition of function Py_INCREF can be found here: link

uint32_t local = _Py_atomic_load_uint32_relaxed(&op->ob_ref_local);

Thus, we add a null value check before calling the function Py_INCREF.

[Jafaral]

@Mergifyio backport dev/10.3 stable/10.2 stable/10.1 stable/10.0

[mergify]

backport dev/10.3 stable/10.2 stable/10.1 stable/10.0

🟠 Waiting for conditions to match

• merged [📌 backport requirement]

[ton31337]

I'd rather replace to Py_XINCREF all the occurrences.

[mugitya03]

Yes, Py_XINCREF first checks for a null value. I'll submit a new PR replacing the API.

[eqvinox]

This is actually not correct as CPython functions are not allowed to return NULL without setting an error. This change coverts a guaranteed crash into indeterminate Python behavior.

[eqvinox]

This work is completely irrelevant since this code is only executed at build time in a controlled environment.

[eqvinox]

I'm going to just NAK this since this is a build-time only tool and if we run out of memory here the build has failed anyway. Considering how memory allocation works, the failure behavior is not sane in any case as the build will start paging and swapping before this happens. Whether we ultimately crash with a SEGV or something nicer is… academic.