New submission from Alexey Izbyshev <>:

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 <>
Python-bugs-list mailing list

Reply via email to