This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author izbyshev
Recipients izbyshev, paul.moore, steve.dower, tim.golden, zach.ware
Date 2018-03-06.22:31:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2018-03-06 22:31:37izbyshevsetrecipients: + izbyshev, paul.moore, tim.golden, zach.ware, steve.dower
2018-03-06 22:31:37izbyshevsetmessageid: <1520375497.65.0.467229070634.issue33016@psf.upfronthosting.co.za>
2018-03-06 22:31:37izbyshevlinkissue33016 messages
2018-03-06 22:31:37izbyshevcreate