-
-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Current (unstable) glib::Regex::match_* API is unsound (use-after-free) #1223
Comments
I think this is the best option here. Anything involving a new heap-allocated buffer internally in the bindings can easily lead to unexpected performance characteristics. |
Do you want to provide a PR for that? |
I have a WIP branch with
|
I'd go with that for now, yes.
Yes
In theory that should already work
That seems fine to me too. This type seems special enough that a manual implementation seems OK |
Okay, I opened a PR (#1225) with the suggested changes. Thanks! |
Bug description
The
GMatchInfo
returned byg_regex_match
references thestring
that was passed tog_regex_match
, but in the Rust bindings,string
is fromIntoGStr::run_with_gstr
, so if anything but a&GStr
or&GString
is passed, it may be a temporaryGString
that is dropped immediately, or a reference to stack memory that later gets reused. Even in the case of passing in a&GStr
or&GString
, the returnedMatchInfo
could be used after the underlyingGStr
/GString
is modified/dropped.Cargo.toml
Backtrace
Backtrace
Running under valgrind
One possible API change to make this sound would be to make
glib::Regex::match_
(and similar) take only&GStr
(notimpl IntoGStr
), and haveMatchInfo
hold a lifetime parameter which expires with that&GStr
borrow, e.g.Another possible change would be to have
glib::MatchInfo
be more than a wrapper aroundGMatchInfo
and have it hold an owned immutable buffer that the innerGMatchInfo
references (i.e. all theRegex::match_*
functions copy the passed string into a new heap-allocated buffer, then call theg_regex_match*
function with that buffer, and return theGMatchInfo
along with the buffer in theglib::MatchInfo
).The text was updated successfully, but these errors were encountered: