Fix a use-after-free bug on Win32 when calling lookupSymbol() #62484
Conversation
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please clean test linux |
|
@swift-ci please test |
|
@swift-ci please test |
| /// | ||
| /// \note This function will be replaced with \c SymbolInfo::lookup() in a | ||
| /// future update. | ||
| static inline int lookupSymbol(const void *address, SymbolInfo *outInfo) { |
There was a problem hiding this comment.
I think that we could out-of-line this function and entirely remove SymbolInfo::lookup, folding the return value handling into the implementation.
There was a problem hiding this comment.
I don't want to get rid of SymbolInfo::lookup(), I want it to be the bottleneck for creating a SymbolInfo instance. The existence of lookupSymbol() at this point could be considered transitional only. Does that make any sense? :)
|
@swift-ci please test windows |
|
Failures don't look related to this branch. Trying clean builds. |
|
@swift-ci please clean test |
…on that calls SymbolInfo:lookup() with a better signature
…std::move() on POD types
grynspan
force-pushed
the
jgrynspan/fix-lookupSymbol-use-after-free
branch
from
d44fed0 to
7de79bd
Compare
|
@swift-ci please test |
|
macOS build failure is on main branch as well. Not a regression. Waiting for it to resolve before rebuilding. |
|
@swift-ci please test macOS |
Fix a use-after-free bug on Win32 when calling
lookupSymbol(). This function populates a structureSymbolInfocontaining a fieldsymbolNamethat is astd::unique_ptr<char, ...>. Several callers of this function get the underlying C string and pass it beyond the scope of theSymbolInfoinstance. Thus, the field can be destructed before the string is used.On platforms with
dladdr(), the string in question is globally owned, so no use-after-free occurs. On Windows, the string is owned by theSymbolInfostructure and is freed when it is destructed. Hence, use-after-free occurs.This change:
SymbolInfoto its own file and provides functions to access its fields, to reinforce that they belong to the symbol info structure and not to the caller.lookupSymbol().symbolNameafter the structure dies to ensure they copy the string. The overhead of copying the string should be swamped by the overhead of callingdladdr()orSymFromAddr().