[zeek/spicy] faf289: Fix ASAN false positive on ARM.

0 views
Skip to first unread message

Robin Sommer

unread,
Sep 4, 2025, 7:21:15 AM (5 days ago) Sep 4
to spicy-...@zeek.org
Branch: refs/heads/topic/robin/fix-asan-fp-on-arm
Home: https://github.com/zeek/spicy
Commit: faf289c8efb4adf15ea863dcbe72cc34e79e821c
https://github.com/zeek/spicy/commit/faf289c8efb4adf15ea863dcbe72cc34e79e821c
Author: Robin Sommer <ro...@corelight.com>
Date: 2025-09-04 (Thu, 04 Sep 2025)

Changed paths:
M hilti/runtime/src/fiber.cc

Log Message:
-----------
Fix ASAN false positive on ARM.

Our fiber code could trigger ASAN to report a false positive: If a
block of memory had already been used before as stack memory for a
previously existing fiber, that usage may have left ASAN guard regions
in place reflecting the state when that old fiber finished. If we were
now reusing the same memory for a new fiber's stack, ASAN would
continue to check any accesses against that old state. So when this
memory now got reinitialized with a new stack structure (i.e.,
essentially writing to arbitrary locations inside the block), those
writes could trigger ASAN to report an out-of-bounds access.

The solution is to explicitly clear that memory with ASAN before
reusing.

This triggered on ARM, but could have just as well triggered in x86 as
well. I think it was just by chance that x86 ended up working.



To unsubscribe from these emails, change your notification settings at https://github.com/zeek/spicy/settings/notifications

Robin Sommer

unread,
3:21 AM (6 hours ago) 3:21 AM
to spicy-...@zeek.org
Branch: refs/heads/main
Home: https://github.com/zeek/spicy
Commit: faf289c8efb4adf15ea863dcbe72cc34e79e821c
https://github.com/zeek/spicy/commit/faf289c8efb4adf15ea863dcbe72cc34e79e821c
Author: Robin Sommer <ro...@corelight.com>
Date: 2025-09-04 (Thu, 04 Sep 2025)

Changed paths:
M hilti/runtime/src/fiber.cc

Log Message:
-----------
Fix ASAN false positive on ARM.

Our fiber code could trigger ASAN to report a false positive: If a
block of memory had already been used before as stack memory for a
previously existing fiber, that usage may have left ASAN guard regions
in place reflecting the state when that old fiber finished. If we were
now reusing the same memory for a new fiber's stack, ASAN would
continue to check any accesses against that old state. So when this
memory now got reinitialized with a new stack structure (i.e.,
essentially writing to arbitrary locations inside the block), those
writes could trigger ASAN to report an out-of-bounds access.

The solution is to explicitly clear that memory with ASAN before
reusing.

This triggered on ARM, but could have just as well triggered in x86 as
well. I think it was just by chance that x86 ended up working.


Commit: f2c5fa3b73418ae69e2eb19214d05fa28d7dad3d
https://github.com/zeek/spicy/commit/f2c5fa3b73418ae69e2eb19214d05fa28d7dad3d
Author: Robin Sommer <ro...@corelight.com>
Date: 2025-09-09 (Tue, 09 Sep 2025)

Changed paths:
M CHANGES
M VERSION
M hilti/runtime/src/fiber.cc

Log Message:
-----------
Merge remote-tracking branch 'origin/topic/robin/fix-asan-fp-on-arm'

* origin/topic/robin/fix-asan-fp-on-arm:
Fix ASAN false positive on ARM.


Compare: https://github.com/zeek/spicy/compare/7635e113080b...f2c5fa3b7341
Reply all
Reply to author
Forward
0 new messages