Skip to content

SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disabled #44369

Closed

Description

@marek-safar

SerializationGuard logic is still used even if EnableUnsafeBinaryFormatterSerialization feature is disabled via feature switch. This brings unnecessary dependencies for size sensitive workloads.

Ideally, code like

would be completely removed as well

Activity

  1. Dotnet-GitSync-Bot commented on Nov 6, 2020

    @Dotnet-GitSync-Bot
    Collaborator

    I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

  2. changed the title [-] SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disables[/-] [+] SerializationGuard is used when EnableUnsafeBinaryFormatterSerialization feature switch is disabled[/+] on Nov 6, 2020
  3. danmoseley commented on Nov 6, 2020

    @danmoseley
    Contributor
  4. GrabYourPitchforks commented on Nov 9, 2020

    @GrabYourPitchforks
    Member

    Serialization Guard isn't a BinaryFormatter-only thing. It's also currently used in DataSet / DataTable:

    DeserializationToken deserializationToken = (_capturedLimiter != null) ? SerializationInfo.StartDeserialization() : default;
    using (deserializationToken)
    {
    return SqlConvert.ChangeType2(argumentValues[0], mytype, type, FormatProvider);
    }

    Interestingly, our implementation of Serialization Guard was the only thing that prevented the original CVE-2020-1147 PoC payload from executing correctly on .NET Core.

    We've had offline discussions about enlightening other serializers like DataContractSerializer and System.Text.Json, and even third-party deserializers like JSON.NET. But TBH these discussions haven't really panned out.

    The runtime crew generally likes the idea of nixing Serialization Guard entirely as a feature. I think eventually we can get there, but if we go this route it should be paired with a renewed effort to excise dangerous serialization code from the ecosystem.

  5. marek-safar commented on Nov 10, 2020

    @marek-safar
    ContributorAuthor

    It's also currently used in DataSet / DataTable

    That API is probably something that will never be used in modern workloads. I'm not sure we actually have to have it at all for example on in the browser.

    Secondly, someone would have to have Switch.System.Data.AllowArbitraryDataSetTypeInstantiation=true option set for the exploit to work, right? We can pair that with EnableUnsafeBinaryFormatterSerialization or some other feature if that's your concern.

    if we go this route it should be paired with a renewed effort to excise dangerous serialization code from the ecosystem.

    Are you pointing to source generators here?

  6. added
    size-reductionIssues impacting final app size primary for size sensitive workloads
    and removed
    linkable-frameworkIssues associated with delivering a linker friendly framework
    on Dec 9, 2020
  7. removed
    untriagedNew issue has not been triaged by the area owner
    on Jul 12, 2021
  8. added this to the Future milestone on Jul 12, 2021
  9. dotnet-policy-service commented on Jan 11, 2026

    @dotnet-policy-service
    Contributor

    Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

    This process is part of our issue cleanup automation.

  10. dotnet-policy-service commented on Jan 25, 2026

    @dotnet-policy-service
    Contributor

    This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.

  11. removed this from the Future milestone on Jan 25, 2026
  12. locked and limited conversation to collaborators on Feb 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-System.Runtimesize-reductionIssues impacting final app size primary for size sensitive workloads

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions