-
-
Notifications
You must be signed in to change notification settings - Fork 339
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
CVE-2021-4022: Segfault when analyzing an ELF64 for HPPA architecture #2015
Comments
Can't reproduce. |
Endless loop, it seems:
|
Sorry, forgot to add: The crash only happens on a release build. When running a debug build, the error condition is catched by the assertion at the beginning of the function |
This is a similar output to the one we saw when we tested this using asan. But I think this isn't an infinite loop: at first a bunch of warnings are produced, but then asan detects a read at an invalid address (that read is triggered by the line Another way to test this is to debug it and set a breakpoint at if (!pc) {
goto out_function; // <---- this goto gets executed
} The goto leads to line 949: out_function:
free(retctx.ret_reg); Skipping the definition of // Create a new context to store the return type propagation state
struct ReturnTypeAnalysisCtx retctx = {
.resolved = false,
.ret_type = NULL,
.ret_reg = NULL
}; Since the invalid free corresponds to an uninitialized variable, depending on the build the severity of the bug changes. For instance, when compiling a release build using the last commit we were able to control the address being |
@OctavioGalland I marked the CVE in the title. I think in the future we could actually just assign them ourselves from Github, WDYT @XVilka @wargio @thestr4ng3r @kazarmy ? |
@ret2libc yes, we did this in the past. |
sounds good to me. |
@OctavioGalland can you confirm that the issue has been patched? |
Yes, it's been fixed. Thanks! |
Work environment
With @ogianatiempo we discovered a bug which makes rizin crash when analyzing certain kind of binaries.
rizin -v
full output, not truncated (mandatory)Expected behavior
Running
aaa
on an ELF64 file shouldn't make rizin crash.Actual behavior
Rizin segfaults.
Steps to reproducebinary the behavior
Run
aaa
(or start rizin with the-A
flag) with the binary namedcrash
attached below.Additional Logs, screenshots, source code, configuration dump, ...
The crash happens in the file
librz/core/analysis_tp.c
at line 950. When analyzing the binary attached below, thegoto
at line 849 is executed, but then at line 950free
is called withretctx.ret_reg
as an argument. The problem is thatretctx.ret_reg
only gets initialized at line 860, but that line never gets executed because thegoto
gets executed first.As a result of this, whatever was on the stack at that time gets
free
ed (for example, in the statically linked release version for linux, the block size will be the value that getsfree
ed).So far, we've only seen the crash happen on a
HPPA
binary. In the archive attached to this issue, we modified the elf header and set the architecture toamd64
and that binary doesn't seem to crash.Here's a bit of information about both binaries:
(the only difference is the target architecture)
And here's the crash in action:
As mentioned before, the binary with
amd64
in the header works well:binaries.zip
The text was updated successfully, but these errors were encountered: