镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

URLHost not robust when re-setting its value #18302

Description

@TimothyGu
  • Version: master
  • Platform: all
  • Subsystem: url, src

Currently, the SetOpaque() and SetDomain() methods of URLHost class in node_url.cc always overwrite the existing string in value_ without disposing of the original value in that union.

node/src/node_url.cc

Lines 95 to 112 in a3555d0

// Setting the string members of the union with = is brittle because
// it relies on them being initialized to a state that requires no
// destruction of old data.
// For a long time, that worked well enough because ParseIPv6Host() happens
// to zero-fill `value_`, but that really is relying on standard library
// internals too much.
// These helpers are the easiest solution but we might want to consider
// just not forcing strings into an union.
inline void SetOpaque(std::string&& string) {
type_ = HostType::H_OPAQUE;
new(&value_.opaque) std::string(std::move(string));
}
inline void SetDomain(std::string&& string) {
type_ = HostType::H_DOMAIN;
new(&value_.domain) std::string(std::move(string));
}
};

This could cause a memory leak when these two methods are used on an instance of the class on which one of these two methods has already been called.

Right now that never happens because of the way the URL parsing state machine is designed, but ideally these two methods should first call this->~URLHost() to free any memory already allocated before reinitializing the value through the new placement.

Activity

  1. added
    whatwg-urlIssues and PRs related to the WHATWG URL implementation.
    c++Issues and PRs that require attention from people who are familiar with C++.
    on Jan 22, 2018
  2. addaleax commented on Jan 22, 2018

    @addaleax
    Member

    this->~URLHost()

    I’m just going to mention again that I’d prefer something like a Reset() method instead that we could call in these setters and in the destructor – calling the destructor of on object explicitly seems pretty icky, especially when we can avoid it. ;)

    (That being said, I’d consider this worthy of being a good first issue if somebody wants to do some C++ stuff?)

  3. apapirovski commented on Jan 23, 2018

    @apapirovski
    Contributor

    I've marked this as a good first issue and mentor available. I'm happy to assist anyone that wants to take this on, it should be a very simple change.

    If anyone's considering this: all that's required is to make a private Reset method on URLHost that contains the current contents of the destructor, then call it from the destructor, SetDomain & SetOpaque.

  4. prog1dev commented on Jan 23, 2018

    @prog1dev
    Contributor

    @apapirovski Alright, I`ll do this one then :)

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

    c++Issues and PRs that require attention from people who are familiar with C++.good first issueIssues that are suitable for first-time contributors.whatwg-urlIssues and PRs related to the WHATWG URL implementation.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions