std.os.windows.GetFinalPathNameByHandle has a reachable unreachable

[paperdave]

Zig Version

0.12.0-dev.1828+225fe6ddb

Steps to Reproduce and Observed Behavior

this happened once when running bun-debug install

it seems this may be possible that the given input handle was already closed when it was attempted to get it's path read.

Since unreachable does not print any information about the state, I cannot report what the path returned from the windows API actually was. I also cannot reproduce this anymore.

Expected Behavior

GetFinalPathNameByHandle returning an error union, should return an error. And if it was to hit unreachable, it should be obvious what the mistake is.

[paperdave]

it is also heavily implied this should work on an invalid file descriptor by the first part of this handling the invalid handle error

[dylan-conway]

Also reproed this a couple times in the last few minutes. final_path was \Device\MountPointManager. Without the expected_prefix, mem.indexOfPos will fail to find the path separator with this path.

[paperdave]

this is a file descriptor use-after-free on our side (i have a custom format function for our FD type, which in debug mode prints the path)

but the case still applies to zig if you query the path of the mount point manager

const std = @import("std");
pub fn main() !void {
    const mgmt_path_u16 = std.unicode.utf8ToUtf16LeStringLiteral("\\??\\MountPointManager");
    const mgmt_handle = try std.os.windows.OpenFile(mgmt_path_u16, .{
        .access_mask = std.os.windows.SYNCHRONIZE,
        .share_access = std.os.windows.FILE_SHARE_READ | std.os.windows.FILE_SHARE_WRITE,
        .creation = std.os.windows.FILE_OPEN,
        .io_mode = .blocking,
    });

    var out: [64000]u16 = undefined;
    _ = try std.os.windows.GetFinalPathNameByHandle(mgmt_handle, .{ .volume_name = .Dos }, &out);
}

[zackradisic]

I also experienced this with this path: \Device\ConDrv

[Jarred-Sumner]

This also happens with \Device\Null