Skip to content

fix(windows): fix socketpair file race condition #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: 5.3.0-semgrep
Choose a base branch
from
Open

fix(windows): fix socketpair file race condition #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion otherlibs/unix/socketpair_win32.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,11 @@ static int socketpair(int domain, int type, int protocol,
goto fail;
}

if (GetTempFileName(dirname, L"osp", 0U, path) == 0) {
static volatile LONG tempfile_counter = 0U;
UINT unique = ((UINT)GetCurrentProcessId() << 16) |
(InterlockedIncrement(&tempfile_counter) & 0xFFFF);

if (GetTempFileName(dirname, L"osp", unique, path) == 0) {
Copy link

@jmgrosen jmgrosen Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will work. The GetTempFileName docs say, "[i]f uUnique is not zero, you must create the file yourself," so the following DeleteFile will fail. (All GetTempFileName seems to be doing with a nonzero uUnique is an sprintf--it doesn't even validate that the file doesn't exist.)

I'm also a little worried about only using the low 16 bits of the process ID and a 16-bit counter--for the process ID, I could see that rolling over in some not-completely-odd scenarios, and same for the counter (even if it wouldn't in semgrep). My suggestion would be to instead follow the GetTempFileName docs' advice:

Due to the algorithm used to generate file names, GetTempFileName can perform poorly when creating a large number of files with the same prefix. In such cases, it is recommended that you construct unique file names based on GUIDs. You can also append the current process ID to the prefix string to reduce the likelihood of collisions in parallel operations.

(Maybe not GUIDs, but a 64-bit random number or something.)

caml_win32_maperr(GetLastError());
goto fail;
}
Expand Down
Loading