fcntl.ioctl raises SystemError: buffer overflow instead of ValueError when mutating undersized buffers

[YuanchengJiang]

Bug report

Bug description:

import fcntl
import termios

with open('/dev/tty', 'rb') as fd:
    fcntl.ioctl(fd, termios.TIOCGPGRP, b'', True)

fcntl.ioctl(fd, termios.TIOCGPGRP, b'', True)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SystemError: buffer overflow

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-144206: Improve error messages for buffer overflow in fcntl.fcntl() and fcntl.ioctl() #144273

[StanFromIreland]

Looking at c2eaeee, the choice appears to be intentional. CC @serhiy-storchaka

[serhiy-storchaka]

Usually Python code should not be able to cause SystemError. But this is a special case. This error happened in case of potential buffer overflow. Python cannot prevent it (unless we add a table for all ioctl() operation codes), it can only detect a misuse of the API post factum. There may be no stack or heap corruption (like in this particular example), but Python does not know this.

[vstinner]

But this is a special case.

Would it make sense to add a parameter to disable overflow check in ioctl()?

[serhiy-storchaka]

And what is an alternative? Crash?

[vstinner]

I misunderstood the issue. fcntl.ioctl(fd, termios.TIOCGPGRP, b'', True) misuses the ioctl() function which requires a pid_t (4 bytes), whereas the function is called with 0 bytes.

I agree that raising a SystemError is the best we can do in this case. The alternative would be to trigger a fatal error.

Python works as expected, and I don't think that anything else should be done, so I suggest closing the issue.

[serhiy-storchaka]

This is actually similar to #141338. Both are not real issues reported by users, but were found by a (semi-)automatic random testing.

I thought about it again and came to the conclusion that SystemError is the correct type of exception. This is very close to the C API misuse. Even if there is no memory corruption, another type of exception can be accidentally silenced.

What can we do -- improve the error message. The benefit of the short error message is that it's generation will less likely fail if the memory corruption occurred, but currently it is not enough clear.