- Wine-GitLab - list.winehq.org

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Elizabeth Figura (＠zfigura) Feb. 25, 2026

Feb. 25, 2026

I don't really understand why we're doing this in the first place. The documentation often claims things that are wrong especially as related to edge cases. If there's not a foreseeable case where RtlGenRandom() could fail (and I don't think memory exhaustion counts as foreseeable either) then I don't think it's worth touching. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130521

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 17:52:11 2026 +0000, Paul Gofman wrote: > Even for ERR I'd also think a formally better place for that would be > ntdll/unix/system.c:read_dev_urandom() (after checking that read to the > requested size actually succeeded). But yet I am still failing to see > how that changes anything in practice, the code is not supposed to fail > there as well. Maybe assert( ret == len ) in the end of the function > (with appropriate move ret definition) would make some sense. Hm, ok so I think this could instead be handled at different level by upgrading the existing `WARN` to `ERR` in `fill_random_buffer` and `assert` the failure case never happens in `SystemFunction036` (aka `RtlGenRandom`). E.g. something like https://gitlab.winehq.org/cdenton/wine/-/commit/93ed99966b316f4c9c1e03af7de… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130519

1 0

Re: [PATCH v2 0/1] MR10021: ntdll: Don't fix gsbase on execution fault exception.
by Brendan Shanks (＠bshanks) Feb. 25, 2026

Feb. 25, 2026

Tested and looks good on an Intel Mac (Rosetta doesn't emulate resetting GSBASE on a `pop %gs`) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10021#note_130513

1 0

Re: [PATCH v10 0/2] MR7064: ntdll: Check for invalid GS base in the 64-bit segv_handler.
by Brendan Shanks (＠bshanks) Feb. 25, 2026

Feb. 25, 2026

Also !10021 fixes an infinite loop when an instruction starts in one page and extends into an inaccessible page -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7064#note_130511

1 0

Re: [PATCH v2 0/1] MR10021: ntdll: Don't fix gsbase on execution fault exception. - approved
by Brendan Shanks (＠bshanks) Feb. 25, 2026

Feb. 25, 2026

This merge request was approved by Brendan Shanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10021

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 17:39:43 2026 +0000, Christopher Denton wrote: > Just to clarify something, would you agree that emitting an `ERR` here > makes sense? Even for ERR I'd also think a formally better place for that would be ntdll/unix/system.c:read_dev_urandom() (after checking that read to the requested size actually succeeded). But yet I am still failing to see how that changes anything in practice, the code is not supposed to fail there as well. Maybe assert( ret == len ) in the end of the function (with appropriate move ret definition) would make some sense. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130509

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 16:11:00 2026 +0000, Paul Gofman wrote: > This whole discussion is focusing on formal handling of return status, > but is missing the fact that read_dev_urandom() in ntdll (the only place > where something can *theoretically* fail outside of process memory > corruption, inventive hotpatching and such) doesn't have error checking > / return at all. If this is a real concern it would make more sense to > check the result and assert there instead of putting wrong things to the > PE side (while I am personally still not sure about how that is useful > too, reading random bytes is not supposed to fail in Unix the same way > as on Windows, reinforcing that system is not totally broken in some > arbitrary places doesn't look too much useful to me). Just to clarify something, would you agree that emitting an `ERR` here makes sense? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130508

1 0

[PATCH 0/1] MR10186: ntdll: Remove unnecessary strdup call
by Nikola Kuburović Feb. 25, 2026

Feb. 25, 2026

Use the wineloader string directly because execv in preloader_exec only reads it, so there should be no worries about it getting modified. Fix the memory leak that happens because duplicated wineloader string memory isn't freed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10186

2 3

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Paul Gofman (＠gofman) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 16:00:26 2026 +0000, Christopher Denton wrote: > The point of having an abort in the function is not security in itself. > The aborting code path should never be hit. If it is then it's a bug in > the underlying implementation that should *ideally* be fixed. And if > such a bug does occur then users shouldn't rely on it (even if > unintentionally). So the `abort` ensure the function fulfils the > documented behaviour even if something else goes wrong. This whole discussion is focusing on formal handling of return status, but is missing the fact that read_dev_urandom() in ntdll (the only place where something can *theoretically* fail outside of process memory corruption, inventive hotpatching and such) doesn't have error checking / return at all. If this is a real concern it would make more sense to check the result and assert there instead of putting wrong things to the PE side (while I am personally still not sure about how that is useful too, reading random bytes is not supposed to fail in Unix the same way as on Windows, reinforcing that system is not totally broken in some arbitrary places doesn't look too much useful to me). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130506

1 0

Re: [PATCH v7 0/1] MR10174: bcryptprimitives: Abort if `ProcessPrng` fails
by Christopher Denton (＠cdenton) Feb. 25, 2026

Feb. 25, 2026

On Wed Feb 25 14:26:15 2026 +0000, Paul Gofman wrote: > Note that we can't protect things this way securely anyway. E. g., if > app does random memory access and hits our random data buffer used in > SystemFunction36, this won't be detected by return value check. The point of having an abort in the function is not security in itself. The aborting code path should never be hit. If it is then it's a bug in the underlying implementation that should *ideally* be fixed. And if such a bug does occur then users shouldn't rely on it (even if unintentionally). So the `abort` ensure the function fulfils the documented behaviour even if something else goes wrong. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130505

1 0