Skip to content

librz/core/canalysis.c: Fix data xref analysis#6612

Open
MrQuantum1915 wants to merge 2 commits into
rizinorg:devfrom
MrQuantum1915:fix/xref-data
Open

librz/core/canalysis.c: Fix data xref analysis#6612
MrQuantum1915 wants to merge 2 commits into
rizinorg:devfrom
MrQuantum1915:fix/xref-data

Conversation

@MrQuantum1915

@MrQuantum1915 MrQuantum1915 commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Your checklist for this pull request

  • I've read the guidelines for contributing to this repository.
  • I made sure to follow the project's coding style.
  • I've documented every RZ_API function and struct this PR changes.
  • I've added tests that prove my changes are effective (required for changes to RZ_API).
  • I've updated the Rizin book with the relevant information (if needed).
  • I've used AI tools to generate fully or partially these code changes and I'm sure the changes are not copyrighted by somebody else.

Detailed description

while processing for marking xrefs as data

  1. classify target using xref_ref_kind for data section too, previously it was only classified if target was in exec segment. Which caused false positive when the target was in non-exec section. Happens when the immediate value is small and it points in data section.

  2. restrict data block from bleeding into other sections. Currently it correctly caps data block at next "detected" function (or next data) but when the function is not detected yet (like in stripped bins) and the area onwards from data ref is empty, the data block bleeds into other sections specifically executable section. This should never happen.

while experimenting on my fix i also noticed that this fails when the target is in a section gap (for any reason :D) and it fallback to caping on map_end.
so we need to iterate over sections if any , to cap upper at next section.

fallback to map end (when target is in last section before unmapped region)

Relevant PRs:
1st bug : #6506
2nd bug : #6307

...

Test plan

  • For 1st bug
    before:
❯ rizin test/bins/elf/hello-freebsd-x64
 -- Use the 'id' command to see the source line related to the current seek
[0x002015a0]> e io.cache=true
[0x002015a0]> s 0x2015ae
[0x002015ae]> wa "and dword [rbp-8], 0x0020001f"
[0x002015ae]> aaa
...
[0x002015ae]> Cdl~0x0020001f
0x0020001f data Cd 5505
[0x002015ae]> 

after:

❯ rizin test/bins/elf/hello-freebsd-x64
 -- Temporally drop the verbosity prefixing the commands with ':'
[0x002015a0]> e io.cache=true
[0x002015a0]> s 0x2015ae
[0x002015ae]> wa "and dword [rbp-8], 0x0020001f"
[0x002015ae]> aaa
...
[0x002015ae]> Cdl~0x0020001f
[0x002015ae]>
  • For 2nd bug i have already mentioned outputs on dev branch in test itself, checkout (those lines which says it should not be....). On dev that are the outputs and hence this test fails on dev
    ...

Closing issues

...

Comment thread librz/core/canalysis.c
Comment on lines +4209 to +4222
ut64 next_sec_start = UT64_MAX;

RzBinSection *s;
void **iter;
rz_pvector_foreach (bo->sections, iter) {
s = *iter;
if (s->is_segment) {
continue;
}
ut64 vaddr = rz_bin_object_addr_with_base(bo, s->vaddr);
if (vaddr > target && vaddr < next_sec_start) {
next_sec_start = vaddr;
}
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering if we should create api fxn for rz_bin_get_next_section or not

@Rot127

Rot127 commented Jul 9, 2026

Copy link
Copy Markdown
Member

Can you give some context why this is needed please?

@MrQuantum1915

MrQuantum1915 commented Jul 9, 2026

Copy link
Copy Markdown
Contributor Author

Can you give some context why this is needed please?

i discussed this in mattermost rizin dev channel
its a bug that prevented aap (preludes analysis) from creating a function at proper place

@Rot127

Rot127 commented Jul 9, 2026

Copy link
Copy Markdown
Member

Sorry, just saw the message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants