In PC/getpathp.c CPython uses buffers with length MAXPATHLEN+1, which is 257 on Windows[1]. On Windows 7, where PathCch* functions are not available, CPython <= 3.8 fallbacks to PathCombineW()/PathCanonicalizeW()[2]. Those functions assume that the destination buffer has room for MAX_PATH (260) characters. This creates a dangerous setup: for example, gotlandmark()[3] can overflow the destination if `filename` is long enough, and `filename` can be user-controlled.

I couldn't devise a simple way to trigger a buffer overflow in a default Python installation, though it is possible if one, for example, makes sure that the landmark file ("lib\os.py") can't be found in the default locations and then supplies their own, long enough paths via e.g. PYTHONPATH environment variable which eventually end up in gotlandmark(). Even when such buffer overflow is triggered on my machine, I couldn't notice any change in behavior, probably because 3 bytes is small enough to not overwrite anything important.

However, I'm not comfortable with this. Could we just raise MAXPATHLEN from 256 to 260 on Windows to avoid such kind of issues for sure?

Please also note that while the issue described above affects only Python <= 3.8 on Windows 7, I think it would make sense to increase MAXPATHLEN in newer versions too to avoid any similar situations in the future (i.e. if two pieces of code interact and one of them uses MAX_PATH while another uses MAXPATHLEN).

[1] https://github.com/python/cpython/blob/0389426fa4af4dfc8b1d7f3f291932d928392d8b/Include/osdefs.h#L13
[2] https://github.com/python/cpython/blob/0389426fa4af4dfc8b1d7f3f291932d928392d8b/PC/getpathp.c#L278
[3] https://github.com/python/cpython/blob/0389426fa4af4dfc8b1d7f3f291932d928392d8b/PC/getpathp.c#L333