Skip to content

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

Closed

Description

@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

Activity

  1. StanFromIreland commented on Jan 24, 2026

    @StanFromIreland
    Member

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

  2. serhiy-storchaka commented on Jan 26, 2026

    @serhiy-storchaka
    Member

    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.

  3. vstinner commented on Jan 27, 2026

    @vstinner
    Member

    But this is a special case.

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

  4. serhiy-storchaka commented on Jan 27, 2026

    @serhiy-storchaka
    Member

    And what is an alternative? Crash?

  5. vstinner commented on Jan 27, 2026

    @vstinner
    Member

    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.

  6. serhiy-storchaka commented on Jan 27, 2026

    @serhiy-storchaka
    Member

    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.

  7. added 2 commits that reference this issue on Jan 27, 2026
  8. added a commit that references this issue on Feb 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    extension-modulesC modules in the Modules dirpendingThe issue will be closed if no feedback is providedtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions