-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Write after free of RetransTableEntry #14446
Comments
#### Problem `ObjectPool` can use either in-line or heap allocation with a platform-configurable default, but several cases still use the original inline-only `BitMapObjectPool`. #### Change overview - Declare pools as `ObjectPool` rather than `BitMapObjectPool` where possible. (Issues for exceptions: project-chip#14444, project-chip#14446) - Remove some empty-on-shutdown checks since the pool normally does this itself (inhibited for asan+heap testing): - ExchangeManager::Shutdown() - ~EndPointManagerImplPool() - Fix many tests to support heap allocation. #### Testing CI; no change to visible functionality expected.
#### Problem `ObjectPool` can use either in-line or heap allocation with a platform-configurable default, but several cases still use the original inline-only `BitMapObjectPool`. #### Change overview - Declare pools as `ObjectPool` rather than `BitMapObjectPool` where possible. (Issues for exceptions: project-chip#14444, project-chip#14446) - Remove some empty-on-shutdown checks since the pool normally does this itself (inhibited for asan+heap testing): - ExchangeManager::Shutdown() - ~EndPointManagerImplPool() - Fix many tests to support heap allocation. #### Testing CI; no change to visible functionality expected.
#### Problem `ObjectPool` can use either in-line or heap allocation with a platform-configurable default, but several cases still use the original inline-only `BitMapObjectPool`. #### Change overview - Declare pools as `ObjectPool` rather than `BitMapObjectPool` where possible. (Issues for exceptions: project-chip#14444, project-chip#14446) - Remove some empty-on-shutdown checks since the pool normally does this itself (inhibited for asan+heap testing): - ExchangeManager::Shutdown() - ~EndPointManagerImplPool() - Fix many tests to support heap allocation. #### Testing CI; no change to visible functionality expected.
#### Problem `ObjectPool` can use either in-line or heap allocation with a platform-configurable default, but several cases still use the original inline-only `BitMapObjectPool`. #### Change overview - Declare pools as `ObjectPool` rather than `BitMapObjectPool` where possible. (Issues for exceptions: project-chip#14444, project-chip#14446) - Remove some empty-on-shutdown checks since the pool normally does this itself (inhibited for asan+heap testing): - ExchangeManager::Shutdown() - ~EndPointManagerImplPool() - Fix many tests to support heap allocation. #### Testing CI; no change to visible functionality expected.
* Replace BitMapObjectPool with configurable ObjectPool #### Problem `ObjectPool` can use either in-line or heap allocation with a platform-configurable default, but several cases still use the original inline-only `BitMapObjectPool`. #### Change overview - Declare pools as `ObjectPool` rather than `BitMapObjectPool` where possible. (Issues for exceptions: #14444, #14446) - Remove some empty-on-shutdown checks since the pool normally does this itself (inhibited for asan+heap testing): - ExchangeManager::Shutdown() - ~EndPointManagerImplPool() - Fix many tests to support heap allocation. #### Testing CI; no change to visible functionality expected. * Leave some pools inline - `ExchangeManager::mContextPool` and `ReliableMessageMgr::mContextPool`: issue #14509 - `GroupSessionTable::mEntries`: issue #14512 * Add chip::Test::PlatformMemoryUser - Add PlatformMemoryUser to manage MemoryInit()/MemoryShutdown() for test contexts that may use heap. - Revert related test changes * restyle
Complicated details to follow. |
Enter Enter Enter CHIP:DMG: RE:Run Cluster fff10002, Attribute fff10004 is dirty At 426: Enter Enter CHIP:DMG: IM RH moving to [AwaitingReportResponse] At 221: Enter Enter Enter CHIP:EM: Piggybacking Ack for MessageCounter:12451190 on exchange: 22567r Here the At 80: CHIP:IN: Prepared secure message 0x7ffff7fb4b88 to 0x000000000001E306 (1) of type 0x5 and protocolId (0, 1) on exchange 22567r with MessageCounter:10983592. At 87: Enter CHIP:IN: Sending encrypted msg 0x7ffff7fb4b88 with MessageCounter:10983592 to 0x000000000001E306 (1) at monotonic time: 1485439570 msec At 289: Enter Enter Enter Enter Enter Enter Here At 557: Enter CHIP:EM: Received message of type 0x5 with protocolId (0, 1) and MessageCounter:10983592 on exchange 22567i At 219: Enter Enter Enter CHIP:EM: Rxd Ack; Removing MessageCounter:12451190 from Retrans Table on exchange 22567i Return to Return to Enter Enter CHIP:DMG: ReportDataMessage = At 504: Enter Enter Enter CHIP:EM: Piggybacking Ack for MessageCounter:10983592 on exchange: 22567i At 87: Enter CHIP:IN: Sending encrypted msg 0x7ffff7fb4ae8 with MessageCounter:12451191 to 0x0000000006A11E3D (1) at monotonic time: 1489749050 msec At 289: Enter Enter Enter Enter Enter Enter Enter CHIP:EM: Received message of type 0x1 with protocolId (0, 1) and MessageCounter:12451191 on exchange 22567r At 219: Enter Enter Enter Here the At 86: CHIP:EM: Rxd Ack; Removing MessageCounter:10983592 from Retrans Table on exchange 22567r Return to Return to CHIP:DMG: StatusResponseMessage = Return to Here we are back in At 102: Enter Here we have read and write of the deleted At 207: |
So the fundamental problem, I expect, is that this test uses the sync-message-delivery loopback mode that I thought we had stopped using.... but it looks like a bunch of tests still use it:
We should probably fix them all to not do that and see whether that addresses this issue. |
Suspected it might be test-only when I hit The Interaction tests and TestReportingEngine hit this; the others pass ASAN. |
There were only two consumers (the retrans table and exchanges) left, which both used to fail unit tests if using ObjectPool due to use-after-free. One of those tests is now fixed; the other is fixed in this PR. So we can move to using ObjectPool everywhere. Fixes project-chip#14509 Fixes project-chip#14446
Looks like this is fixed now that all the unit tests use async messaging. I just tried making the retrans table into an ObjectPool and it passes for me. See #20058 |
There were only two consumers (the retrans table and exchanges) left, which both used to fail unit tests if using ObjectPool due to use-after-free. One of those tests is now fixed; the other is fixed in this PR. So we can move to using ObjectPool everywhere. Fixes project-chip#14509 Fixes project-chip#14446
TestReadInteraction::TestReadChunking()
exhibits a use-after-free of aRetransTableEntry
.Original description (not that it is not necessary to use a heap pool for the use-after-free to occur, but it's harder to trace):
Problem
If
ReliableMessageMgr::mRetransTable
is a heap-allocated pool,TestReadInteraction
aborts:This is surprising and may indicate an underlying memory safety problem.
Proposed Solution
Investigate and resolve.
The text was updated successfully, but these errors were encountered: