New submission from Alexey Izbyshev <izbys...@ispras.ru>: The first call of GetFinalPathNameByHandleW requests the required buffer size for the NT path (VOLUME_NAME_NT), while the second call receives the DOS path (VOLUME_NAME_DOS) in the allocated buffer. Usually, NT paths are longer than DOS ones, for example:
NT path: \Device\HarddiskVolume2\foo DOS path: \\?\C:\foo Or, for UNC paths: NT path: \Device\Mup\server\share\foo DOS path: \\?\UNC\server\share\foo However, it is not always the case. A volume can be mounted to an arbitrary path, and if a drive letter is not assigned to such a volume, GetFinalPathNameByHandle will use the mount point path instead of C: above. This way, a DOS path can be longer than an NT path. Since the result of the second call is not checked properly, this condition won't be detected, resulting in an out-of-bounds access and use of uninitialized memory later. Moreover, the path returned by GetFinalPathNameByHandle may change between the first and the second call, for example, because an intermediate directory was renamed. If the path becomes longer than buf_size, the same issue will occur. ---------- components: Extension Modules, Windows messages: 313366 nosy: izbyshev, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: nt._getfinalpathname may use uninitialized memory type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33016> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
