Bugzilla

The early reports after publishing 115.0.2 suggest that we have successfully fixed this issue for the vast majority of affected users. However, there could will likely be a few reports coming from a small portion of these users (currently, 1).

This is most likely users for whom the launcher process fails to start. The current fix blocks the malicious DLL from within the launcher process blocklist code, so, if the launcher process fails to start, the DLL won't be blocked: we will be using the fallback mozglue blocklist code instead (I can confirm this by testing this with pref `browser.launcherProcess.enabled` to `false`).

I'm reopening this bug as a reminder that we are not yet completely done with this crash, although the volume should be very significantly diminished now.

The early reports after publishing 115.0.2 suggest that we have successfully fixed this issue for the vast majority of affected users. However, there will likely be a few reports coming from a small portion of these users (currently, 1).

This is most likely users for whom the launcher process fails to start. The current fix blocks the malicious DLL from within the launcher process blocklist code, so, if the launcher process fails to start, the DLL won't be blocked: we will be using the fallback mozglue blocklist code instead (I can confirm this by testing this with pref `browser.launcherProcess.enabled` to `false`).

I'm reopening this bug as a reminder that we are not yet completely done with this crash, although the volume should be very significantly diminished now.

The early reports after publishing 115.0.2 suggest that we have successfully fixed this issue for the vast majority of affected users. However, there will likely be a few reports coming from a small portion of these users (currently, 1).

This would be users for whom the launcher process fails to start. The current fix blocks the malicious DLL from within the launcher process blocklist code, so, if the launcher process fails to start, the DLL won't be blocked: we will be using the fallback mozglue blocklist code instead (I can confirm this by testing this with pref `browser.launcherProcess.enabled` to `false`).

I'm reopening this bug as a reminder that we are not yet completely done with this crash, although the volume should be very significantly diminished now. To fix this, we could port the patch to the fallback mozglue blocklist.

The early reports after publishing 115.0.2 suggest that we have successfully fixed this issue for the vast majority of affected users. However, there will likely be a few reports coming from a small portion of these users (currently, 1).

This would be users for whom the launcher process fails to start. The current fix blocks the malicious DLL from within the launcher process blocklist code, so, if the launcher process fails to start, the DLL won't be blocked: we will be using the fallback mozglue blocklist code instead (I can confirm this by testing with pref `browser.launcherProcess.enabled` set to `false`).

I'm reopening this bug as a reminder that we are not yet completely done with this crash, although the volume should be very significantly diminished now. To fix this, we could port the patch to the fallback mozglue blocklist.

The early reports after publishing 115.0.2 suggest that we have successfully fixed this issue for the vast majority of affected users. However, there will likely be a few reports coming from a small portion of these users (currently, 1).

This would be users for whom the launcher process fails to start. The current fix blocks the malicious DLL from within the launcher process blocklist code, so, if the launcher process fails to start, the DLL won't be blocked: we will be using the fallback mozglue blocklist code instead. I can confirm this by testing with pref `browser.launcherProcess.enabled` set to `false`.

I'm reopening this bug as a reminder that we are not yet completely done with this crash, although the volume should be very significantly diminished now. To fix this, we could port the patch to the fallback mozglue blocklist.

The early reports after publishing 115.0.2 suggest that we have successfully fixed this issue for the vast majority of affected users. However, there will likely be a few reports coming from a small portion of these users (currently, 1).

This would be users for whom the launcher process fails to start. The current fix blocks the malicious DLL from within the launcher process blocklist code, so, if the launcher process fails to start, the DLL won't be blocked: we will be using the fallback mozglue blocklist code instead. I can confirm this by testing with pref `browser.launcherProcess.enabled` set to `false`.

I'm reopening this bug as a reminder that we are not yet completely done with this crash, although the volume should be very significantly diminished now. To fix this completely, we could port the patch to the fallback mozglue blocklist.