- Wine-gitlab - list.winehq.org

Re: [PATCH v6 0/1] MR10174: bcryptprimitives: Make ProcessPrng always return `TRUE`
by Christopher Denton (＠cdenton) 24 Feb '26

24 Feb '26

On Tue Feb 24 15:53:32 2026 +0000, Paul Gofman wrote: > At very least, that could maybe use some test, if there are reasons why > it is useful which I am missing. What will happen on Windows if the > buffer is invalid (or unaligned) pointer, if buffer is NULL, if size is > ~0u? Will it cause access violation, program abort without exception or > maybe will just fail with an error? Testing on Windows, it causes an access violation if the buffer is NULL or otherwise not writeable. I've not found any other cases that fail. It works on bytes so alignment isn't an issue. Looking at the implementation of `get_random` in https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/system.c#…, it doesn't look like the wine implementation can fail either except if the buffer is NULL. The only place I can see that returns an error is: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/system.c#… ```c len = peb->NumberOfProcessors * sizeof(SYSTEM_INTERRUPT_INFORMATION); if (size >= len) { if (!info) ret = STATUS_ACCESS_VIOLATION; else get_random( info, len ); } ``` The `if (size >= len)` check in that function will trivially succeed because the `fill_random_buffer` function ensures that `size` is small enough. And if `NtQuerySystemInformation` returns successfully then every other function up the chain will return successfully too. So it seems the behaviour is aligned with Windows except for that NULL check. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130382

1 0

[PATCH v6 0/3] MR9915: mmdevapi: Device name changes.
by Bernhard Kölbl (＠besentv) 24 Feb '26

24 Feb '26

Phasmophobia needs this to get in-game voice chat working. -- v6: mmdevapi: Adjust device names. mmdevapi/tests: Check device friendly name pattern. mmdevapi/tests: Simplify a trace. https://gitlab.winehq.org/wine/wine/-/merge_requests/9915

3 4

[PATCH v12 0/8] MR10019: opengl32: Move wglGetProcAddress implementation to the PE side.
by Rémi Bernon (＠rbernon) 24 Feb '26

24 Feb '26

This better splits client / host extension lists, allowing to more easily check for available host-side extensions in win32u later on, then moves the function registry to the PE side to get rid of the remaining extension logic in opengl32 unix side. Doing that, it also drops the driver function check, and always expose extension functions to the client if their extension dependency is satisfied. I'm not completely sure this is right, but I think the unix side tends to expose functions from eglGetProcAddress more often than the opposite. We could also keep a mechanism to check the driver availability, with a bit of additional complexity. On the unix side, all OpenGL functions are queried on initialization instead of just core functions, simplifying their use later on. -- v12: opengl32: Implement the function registry on the PE side. win32u: Query every OpenGL functions on initialization. opengl32: Implement client extension enumeration on the PE side. opengl32: Move major / minor version to the PE side context wrapper. opengl32: Parse host extension list to the opengl_extensions struct. opengl32: Remove now unused wgl pixel format unix thunks. opengl32: Implement wglGetExtensionsString(ARB|EXT) on the PE side. opengl32: Initialize enabled / disabled OpenGL extensions struct. https://gitlab.winehq.org/wine/wine/-/merge_requests/10019

2 9

Re: [PATCH v6 0/1] MR10174: bcryptprimitives: Make ProcessPrng always return `TRUE`
by Paul Gofman (＠gofman) 24 Feb '26

24 Feb '26

At very least, that could maybe use some test, if there are reasons why it is useful which I am missing. What will happen on Windows if the buffer is invalid (or unaligned) pointer, if buffer is NULL, if size is ~0u? Will it cause access violation, program abort without exception or maybe will just fail with an error? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130375

1 0

[PATCH v5 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) 24 Feb '26

24 Feb '26

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v5: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

4 4

[PATCH v4 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) 24 Feb '26

24 Feb '26

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v4: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

3 2

[PATCH v3 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) 24 Feb '26

24 Feb '26

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v3: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

2 1

[PATCH v2 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
by Christopher Denton (＠cdenton) 24 Feb '26

24 Feb '26

[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper. > We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request. [`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-… -- v2: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174

4 7

[PATCH 0/1] MR10178: compiler-rt: add __ctzdi2 to fix i386 mingw builds
by Maotong Zhang (＠xiaotong) 24 Feb '26

24 Feb '26

Commit 8d8d871b switched mingw from -lgcc to compiler-rt. This breaks i386 builds with ccache: Capstone fails to link (AArch64/ARM disassemblers) due to an undefined __ctzdi2 symbol. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10178

2 1

[PATCH 0/1] MR10177: ntdll: Fix threadpool timer behavior on system time change.
by Piotr Caban (＠piotr) 24 Feb '26

24 Feb '26

Threadpool timers are not handling system clock changes correctly. Observed while trying to start delayed-start service on DST change (service started after 1h02m instead of 2m). These patch changes threadpool timers to use NtCreateTimers internally. It matches with native implementation as documented here: https://github.com/SafeBreach-Labs/PoolParty. While it moves implementation closer to what native does I didn't work on making it binary compatible. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10177

2 1