Jump to content

BSOD after KB4056894 - Meltdown + Spectre Patch?


Recommended Posts

Hi,

I've just repaired a Dell Inspiron laptop (Windows 7 Home Premium 64-bit, AMD Turion X2 DC Mobile RM-74 2.20 GHz) that suffered a STOP 0x000000C4 BSOD message on each Windows restart attempt, with no access to any safe modes, I found a fix online...

https://answers.microsoft.com/en-us/windows/forum/windows_7-update/stop-0x000000c4-after-installing-kb4056894-2018-01/f09a8be3-5313-40bb-9cef-727fcdd4cd56?auth=1&rtAction=1515190079156

...that suggested removing the KB4056894 patch using the dsim command from Windows 7 recovery environment.  This fixed the blue screen on re-boot.  I've now disabled it's re-installation within the Windows Update settings.

On further reading...

https://support.microsoft.com/en-gb/help/4056894/windows-7-update-kb4056894

it appears that this fix is only applicable (installed?) to PCs "where the Anti virus ISV have updated the ALLOW REGKEY.".

According to the ESET forum page on the Meltdown + Spectre CPU vulnerabilities...

https://forum.eset.com/topic/14274-esets-response-to-meltdown-and-spectre-cpu-vulnerabilities/

...ESET have released module update 1533.3 - "to ensure compatibility with Microsoft's updates to the Windows operating systems".

The laptop, while running ESET Smart Security version 8.0.316.0, does have module 1533.3 installed.

Q1.    Is KB4056894 anything to do with patching Meltdown/spectre CPU vulnerabilities?

Q2.   If so why does the laptop with module 1533.3 installed suffer the BSOD on restarts?

Q3.   Will this occur on all my client PCs when KB4056894 is automatically delivered over the next days/weeks?

Thanks in advance

PS:  To double check the  error, I  repeated the KB4056894 install via WU and it resulted in the same BSOD - just in case the ESET module 1533.3 was not installed prior to the Windows update first occurring (last week).

Mike

 

 

Link to comment
Share on other sites

  • Administrators

1, Yes, that update rollup contains also fixed for the Meltdown vulnerability.

2, It appears that for quite many users this update has caused more harm then good: http://news.softpedia.com/news/microsoft-s-windows-7-meltdown-and-spectre-patch-kb4056894-failing-with-bsod-519264.shtml.

3, Hard to say. We believe that the crashes are not caused by ESET. We recommend configuring Windows to generate complete memory dumps as per https://support.eset.com/kb380 prior to installing the updates so that we can determine the cause of a crash if something goes wrong.

Link to comment
Share on other sites

Marcos.

Since my post, I checked the registry file and the key that Microsoft recommend being installed  is clearly showing - hence the delivery of KB4056894 I guess?

I will follow your instructions in ESET kb380 on the laptop with the BSOD and try and get the data to you if it helps determine the likely cause of the fault, hopefully not ESETs! I will apply the SP on other PCs of mine to see if I can replicate the problem on Intel CPU systems.

I guess I may be getting a lot of phone calls in the coming days....

Many thanks
Mike

 

Link to comment
Share on other sites

1 hour ago, F1-Local said:

The laptop, while running ESET Smart Security version 8.0.316.0, does have module 1533.3 installed.

Q1.    Is KB4056894 anything to do with patching Meltdown/spectre CPU vulnerabilities?

Q2.   If so why does the laptop with module 1533.3 installed suffer the BSOD on restarts?

Q3.   Will this occur on all my client PCs when KB4056894 is automatically delivered over the next days/weeks?

For starters, this has nothing to do with your Eset security software. All Eset did was to update a registry key to allow the Microsoft patches to be installed via Win Updates. If you remove the registry key Eset updated, this should stop an further KB4056894 download via Win Updates. Note I wrote "should stop."

The registry key added is:

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”

The KB4056894 Win 7 patch problems only affect certain AMD processors. The processors affected are listed in the first Microsoft link you posted.

Unlike Win 10 that automatically will download all available Win Updates, you can control in Win 7 what is or isn't downloaded by unchecking a given KB. However, you have to turn off any automatic Win Updating to do so.

Note the following in regards to whether the Win 7 Meltdown and Spectre fixes are necessary and respond accordingly:

1. AMD processors are not vulnerable to the Meltdown exploit. AMD has publically stated the a Spectre attack against their processors is theoretically possible but highly unlikely. I believe their wording was "extremely low possibility."

2. The Microsoft Meltdown and Spectre exploit patches not only include OS mitigations but patches to select Microsoft software such as IE11, MS Office, Adobe Flashplayer, etc. for Win 7.

Edited by itman
Link to comment
Share on other sites

On further reading (after my second post) I've now realised the minor role that AV vendors play, but thanks for the confirmation.

I did read one forum where a user experienced the associated BSOD on their Intel Core i7 machine, hence that's why I'm keen to look at my Intel PCs.  This BSOD issue is fairly new, is it likely all CPU types have been isolated?  That said, I would expect to see more reports of Intel based systems suffering - by the law of averages.

Given that you say that the fault is nothing to do with ESET, is it still OK to submit a memory dump to you, as suggested by Marcos?  Do you only need  the memory dump prior to the update installing?

Mike

 

Link to comment
Share on other sites

According to this:

Quote

Oddly, all of the Win7 blue screen reports I've seen are associated with the 2018-01 Monthly Rollup. The manual-download Security Only update hasn't had as many problems. Or, at least, as many reported problems.

https://www.computerworld.com/article/3246286/microsoft-windows/buggy-win7-meltdown-patch-kb-4056894-throwing-blue-screens.html

You might want to try a test by just installing KB4056894 stand-alone.

Link to comment
Share on other sites

I tried installing KB4056894 stand-alone and it failed to install and caused a BSOD on restart.  Identical behaviour as when installed via WU in the monthly rollup.

I then removed ESET from the laptop and installed KB4056894 stand-alone again.  Same result and BSOD on restart, confirming it has nothing to do with ESET.  No need to submit any memory dumps to you now!

From the MS page on KB4056894...

https://support.microsoft.com/en-gb/help/4056894/windows-7-update-kb4056894

...it appears that they have updated advice and have themselves stopped the update rollout to affected AMD devices.  I guess this overrides the installed registry key?

 

Q1.   Is the registry key merely a simple 'green light' for the MS code to deliver KB4056894 (and all subsequent MS patches)?  Or does it have any other impact on the system?

Q2.   By adding this registry key, are AV vendors effectively saying that their software does NOT bypass Kernel Patch Protection and is therefore compatible?

Q3.   I assume that an AV product that DOES patch the kernel could possibly cause problems with subsequent MS patches for Meldown and Spectre CPU vulnerabilities - as described in the doublepulsar article above (...changing memory locations etc.)?

Q4.   What if a PC has NO AV installed, are MS not delivering any new patches to these PCs?  Will manually adding the registry key allow future MS patches?

Thanks for your patience!

Link to comment
Share on other sites

3 hours ago, F1-Local said:

Q1.   Is the registry key merely a simple 'green light' for the MS code to deliver KB4056894 (and all subsequent MS patches)?  Or does it have any other impact on the system?

 

3 hours ago, F1-Local said:

Q4.   What if a PC has NO AV installed, are MS not delivering any new patches to these PCs?  Will manually adding the registry key allow future MS patches?

Based on what was posted in the doublepulsar.com linked article I posted, it appears that Microsoft is "cracking down" on AV vendors and requiring them to in essence certify that their software will not cause any problems with future Win OS upgrades. That is the purpose of the creation of the AV registry key. If this key does not exist in the registry, it appears future Win Updates will not be delivered to any device where it is missing from.

As far as your Q2. and Q3, I believe Microsoft is engaging in a Pontius Pilot "hand washing" routine and publically stating that due to these AV practices, any future Win update issues are due to third party AV like practices. Personally, I believe this is a bunch of BS and Microsoft is just pursuing their end strategy to dominate the AV software market with its own solutions. Whereas many of those solutions are currently provided at no cost, rest assured that will not be the case in the future if Microsoft can monopolize the security software market. They will then be offered only as annual subscription services such as Windows Defender ATP currently is. 

Edited by itman
Link to comment
Share on other sites

FYI - came across this in another security forum:

Quote

At a slight tangent, FWIW I was repeatedly having these BSODs post KB4056892: Error: UNEXPECTED_KERNEL_MODE_TRAP_M

This is the corresponding Meldown/Spectre patch for Win 10. Turns out the OP had a driver loading from AV software previously used and long ago uninstalled. Appears its realtime driver wasn't uninstalled though.  So indeed resident software traces currently installed that "intrude" into kernel space could be a cause of these Blue Screens.

Link to comment
Share on other sites

You make an interesting point regarding Microsoft's end strategy, however, what are AV vendors 'signing up' to when deciding to add the registry key?  Are they effectively 'saying' that they do NOT bypass the KPP - that the doublepulsar.com talks about?

Do some AV products actually bypass the KPP?  If they do and this practice does cause stability problems with future Microsoft patches (for Meltdown and Spectre) why wouldn't Microsoft just let it happen and have a field day in the press when it occurs and they get to blame the AV vendor(s) for 'dodgy' practices? The bad press would surely cause massive damage to the AV Vendors at that stage, if Microsoft control the narrative?

I guess, if a vendor adds the registry key knowing that their product does bypass the KPP, Microsoft potentially have a stronger hand if system's become unstable in the future -  by accusing AV vendors of false claims regarding product compatibility?  A more subtle (and legal approach) I presume?

Are Microsoft imposing these conditions on other rival software or hardware vendors where they share the market?

Interesting times...

Link to comment
Share on other sites

37 minutes ago, F1-Local said:

Are they effectively 'saying' that they do NOT bypass the KPP - that the doublepulsar.com talks about?

Doubt that. However if they do, it "opens the door" for Microsoft to point the finger at them for any future botched Win Update kernel patch they might issue.

The "problem" is KPP is currently a security joke and has been bypassed on numerous occasions. And the whole issue will get much messier in the near future with Microsoft pushing Win 10 Hyper-V based virtualization protection down to the application level.

Link to comment
Share on other sites

Seems ironic that the AMD processors are the ones suffering from the Microsoft patches to the CPU vulnerabilities that aren't supposed to affect AMD......

Link to comment
Share on other sites

43 minutes ago, F1-Local said:

aren't supposed to affect AMD

If you are willing and since it appears all your AMD processor devices are unpatched, there is a way to validate AMD's claim Spectre risks are very low.

If you have an AMD device isolated from your internal network, you can go to this website: http(s)://repl.it/repls/DeliriousGreenOxpecker. Click on the "Run" tab and it simulates a browser based Spectre attack. If you see the wording "The Magic Words are Squeamish Ossifrage" in the displayed right hand side output, your browser cache data can be intercepted.

A bit of what is going on with this test. A javascript is run on the web page that will connect to a remote web server that will run the simulated attack code. It's a "safe" server but as nothing can be guaranteed these days, you might want to do an image backup of your test machine first.

If the test displays the above noted wording, then we can conclude once and for all that Microsoft OS and app patching is required.  

The actual proof of concept is here along with tests against various processors shown in the comments: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

Edited by itman
Link to comment
Share on other sites

  • Most Valued Members
12 hours ago, F1-Local said:

I guess, if a vendor adds the registry key knowing that their product does bypass the KPP, Microsoft potentially have a stronger hand if system's become unstable in the future -  by accusing AV vendors of false claims regarding product compatibility?  A more subtle (and legal approach) I presume?

Just to throw another spanner in the works. Once this registry key is added by whatever vendor you use as it is "compatible" , it could also subsequently lead to further problems down the road if you then install another (secondary) security product that is not "compatible" :rolleyes:.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...