.NET December 2021 Updates – 6.0.1, 5.0.13 and 3.1.22

Sanket Kalaskar

Today, we are releasing the .NET December 2021 Updates. These updates contain reliability and security improvements. See the individual release notes for details on updated packages.

You can download 6.0.1, 5.0.13 and 3.1.22 versions for Windows, macOS, and Linux, for x86, x64, Arm32, and Arm64.

Improvements

Security

CVE-2021-43877: ASP.NET Core Information Disclosure Vulnerability

Microsoft is releasing this security advisory to provide information about a vulnerability in .NET and .NET Core. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

An elevation of privilege vulnerability exists in ASP.NET Core Module (ANCM) that could allow elevation of privilege when .NET Core, .NET 5 and .NET 6 applications are hosted within IIS.

Deployment Update

Customers that have opted to receive .NET Core updates via the Microsoft Update channel will be offered updates to the Hosting Bundle starting with the December 2021 update. Updates for other .NET Core bundles (.NET Core Runtime, ASP.NET Core Runtime, Windows Desktop Runtime, and SDK) have been offered via Microsoft Update to customers that opt in since December 2020. See this blog post for more information.

Visual Studio

See release notes for Visual Studio compatibility for .NET 6.0, .NET 5.0, and .NET Core 3.1.

Known Issue: Failure to install the .NET 6.0.1 update via Microsoft Update

There have been limited reports of a failure to install the .NET 6.0.1 update via Microsoft Update, the update fails with an error code 0x80070643.

.NET 6.0 can be updated to 6.0.1 via MU and .NET 6.0.1 is also included in the Visual Studio 17.0.3 update. Both options carry the .NET Core Runtime and ASP.NET Core runtime version 6.0.1 and the .NET 6 SDK version 6.0.101. When these are installed, applications will by default roll forward to using the latest runtime patch version automatically. See [framework dependent app runtime roll forward](https://docs.microsoft.com/en-us/dotnet/core/versions/selection#framework-dependent-apps-roll-forward) for more information about this behavior.

Therefore, installing either the 6.0.1 update via MU or the VS 17.0.3 update will secure the machine for the vulnerability described in [CVE-2021-43877](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43877).

17 comments

Comments are closed. Login to edit/delete your existing comments

  • selcuk caglar

    Windows 11
    2021-12 .NET 6.0.1 Security Update for x64 Client (KB5009191)
    Install error – 0x80070643
    Troubleshot couldn’t fix it. I don’t know what is working in behind.

  • Jason Baginski

    FYI, WinForm apps “close-stuck” when upgrading the desktop runtime. They disappear from the task bar, but they are still listed running in task manager. Previously they’d just completely close(which is a problem itself). Now they appear to close, but they are still loaded in memory/files locked. Have to use task manager to kill the processes and restart them.

  • Jimmy Xie

    It seems that the symbol files are not uploaded to the symbol file server msdl.microsoft.com.
    The server says ” ERROR: Not Found: libSystem.Globalization.Native.so.dbg – ‘http://msdl.microsoft.com/download/symbols/.debug/elf-buildid-sym-2a934a340f4219ec2e4c9f57e6ec2a3cb298333d/.debug’ “.

  • Jason S. Clary

    This appears to break the experimental generic math feature. Projects that use it fail to build after this update is applied. The types are still there in System.Private.CoreLib according to reflection but can’t be found at build time when used in a project. Apparently the runtime is now ignoring the options in the project file that enable the feature.

    The same build of the SDK (Version: 6.0.101 Commit: ef49f6213a) and Host (Version: 6.0.1 Commit: 3a25a7f1cc) on Linux has the same problem. I had not tried it previously on Linux but it failed with this version and then I tested it on Windows where it worked until I fixed the failed installation of this update. Now it doesn’t work on either.

    See Tanner’s devblogs post for details about the feature and how to enable it.

    The feature is a tad esoteric but many of us have been asking for it for over a decade now. Given that it is experimental and not well advertised, it’s hard to tell how many people might be using it. There are at least a few nuget packages that depend on System.Runtime.Experimental, however, and I know a number of people that are excited about the feature.

    Edit: There is an open issue for this on github with a viable workaround.

  • mess84

    I’m going to counter argue Hosting Bundle being updated…
    The underlying ASP.NET Core Shared Frameworks (x64 & x86) are updated.
    The underlying .NET Core Runtimes (x64 & x86) are updated.
    This is leaving behind aspnetcorev2.dll (under C:\Program Files\IIS\Asp.Net Core Module\V2) on the original vulnerable version.
    image
    This particular server is patched via SCCM (CB) up until today we have not been syncing the WSUS classification/products for dotnet core. I have turned it on today, forced a SUP sync and created and ADR which is targeting a couple of test machines.

    I was expecting to see 3.1.22 also? But it appears only 3.1.21 is available via WSUS? and no hosting bundle / ANCM at all?! This could lull a lot of people into a false sense of security. Has 3.1.22 been pulled / ever published via WSUS?