summaryrefslogtreecommitdiff
path: root/debuggerd/handler/debuggerd_handler.cpp
diff options
context:
space:
mode:
authorMitch Phillips <mitchp@google.com>2021-01-21 20:41:50 -0800
committerMitch Phillips <mitchp@google.com>2021-01-21 20:49:06 -0800
commite4adff0721930dcb6969245bfa298b6abd48d2d4 (patch)
treed2887b534e002d17c2df01b723681620191ddf22 /debuggerd/handler/debuggerd_handler.cpp
parent79f7e3f1fc900519b4eebd0674e18f0aa0d7fd42 (diff)
[MTE] Cleanup tagged si_addr refs to fix mappings OOB bug.
Currently, all MTE failures end up displaying 'Fault address falls at 0x<addr> after any mapped regions'. Clearly when scanning, we should use the untagged address to figure out which ranges it's in. I've taken the liberty of removing all si_addr parsing and moving it into the common ProcessInfo, as well as making it really explicit whether you want the (possibly tagged) original si_addr, or whether you want the untagged variant (for scanning /proc/maps or whatever). This is not particularly easily testable, as ReadCrashInfo isn't easily injectable and `dump_all_maps` should already be passed the untagged pointer to scan for. I've tested this locally on FVP under SYNC MTE with a simple UaF binary and noted the problem is fixed. Given that this is making the code more clear, I'm hoping the owners see no need for a regression test :). Bug: 135772972 Test: On FVP, run 'adb shell MEMTAG_OPTIONS=sync sanitizer-status' and check that the use-after-free test ends up with the /proc/maps desription in the right place. Change-Id: I220e4200c75a72474a95a67e5bbc36173a438dd2
Diffstat (limited to 'debuggerd/handler/debuggerd_handler.cpp')
0 files changed, 0 insertions, 0 deletions