You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fcntl.ioctl raises SystemError: buffer overflow instead of ValueError when mutating undersized buffers #144206
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.
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.
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.
Activity
StanFromIreland commentedon Jan 24, 2026
Looking at c2eaeee, the choice appears to be intentional. CC @serhiy-storchaka
serhiy-storchaka commentedon Jan 26, 2026
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 commentedon Jan 27, 2026
Would it make sense to add a parameter to disable overflow check in ioctl()?
serhiy-storchaka commentedon Jan 27, 2026
And what is an alternative? Crash?
vstinner commentedon Jan 27, 2026
I misunderstood the issue.
fcntl.ioctl(fd, termios.TIOCGPGRP, b'', True)misuses theioctl()function which requires apid_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 commentedon Jan 27, 2026
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.
pythongh-144206: Improve error messages for buffer overflow in fcntl.…
gh-144206: Improve error messages for buffer overflow in fcntl.fcntl(…
pythongh-144206: Improve error messages for buffer overflow in fcntl.…