Repository navigation
linux: Make syscall-trace strings valid UTF-8 - #1285
Merged
Merged
Conversation
g_variant_new_string() returns NULL when given invalid UTF-8, and the g_variant_ref_sink() that Vala adds around it then dereferences the NULL, crashing frida-server. Module paths in resolve-symbols, and string arguments and AF_UNIX socket paths in read-events, come from /proc/<pid>/maps and from the kernel, so they can hold any byte. Replace invalid sequences before they go into a GVariant.
Member
|
Thanks! 🙌 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
frida-server crashes (SIGSEGV) when the
syscall-traceservice is asked for symbols of, or events from, a process that uses a file or socket whose name is not valid UTF-8.g_variant_new_string()returns NULL for invalid UTF-8 (after aGLib-CRITICAL), and theg_variant_ref_sink()that Vala adds around it then dereferences the NULL. Two places feed it bytes that come straight from/proc/<pid>/mapsor the kernel:resolve-symbols: the module paths of the process. They come from/proc/<pid>/mapsand from the dentry paths of eBPFMAP_CREATEevents.read-events: string arguments such as the path passed toopenat(), andAF_UNIXsocket paths such as the address passed toconnect().Both are now passed through
make_valid (), so invalid sequences become U+FFFD. Valid strings are unchanged and the wire format stays the same.The eBPF paths are not specific to #1284: on
mainand on the 17.25.2 release, a process that maps a file nameddat\xffxyafter attach, callsopenat()ondata\xff, or callsconnect()on the socket paths\xfftakes frida-server down. The/proc/<pid>/mapspath becomes reachable with #1284, which lets such lines through instead of dropping the whole parse.Tested on Ubuntu 24.04.5 (aarch64, kernel 6.8.0-117-generic) with release builds of frida-server (
./configuredefaults), sending the requestsfrida-stracesends (get-signatures,add-targets,read-events,resolve-stacks,resolve-symbols):mainmain+ this change/data/t/dat\xffxy(eBPF map event)/data/t/dat�xy, server aliveopenat("/data/t/data\xff")read-events/data/t/data�, server aliveconnect()to/data/t/s\xff, or to the abstract name\xff\xferead-events/data/t/s�or��, server alive/data/t/datéx(valid UTF-8)datéxdatéxWith #1284 (
9fd003d9), a traced process started from/data/t/yes\xffalso exits 139 onresolve-symbols; with this change on top, the module list contains/data/t/yes�and the server stays up.No test is added: the repository has none for the syscall-trace service, and exercising it needs eBPF privileges.