V0.11.1, connectd crash #5284
Comments
whitslack
added a commit
to whitslack/lightning
that referenced
this issue
May 30, 2022
`peer_reconnected` was freeing a `struct peer_reconnected` instance while a pointer to that instance was registered to be passed as an argument to the `retry_peer_connected` callback function. This caused a use-after-free crash when `retry_peer_connected` attempted to reparent the instance to the temporary context. Instead, never have `peer_reconnected` free a `struct peer_reconnected` instance, and only ever allow such an instance to be freed after the `retry_peer_connected` callback has finished with it. To ensure that the instance is freed even if the connection is closed before the callback can be invoked, parent the instance to the connection rather than to the daemon. Absent the need to free `struct peer_reconnected` instances outside of the `retry_peer_connected` callback, there is no use for the `reconnected` hashtable, so remove it as well. See: ElementsProject#5282 (comment) Fixes: ElementsProject#5282 Fixes: ElementsProject#5284 Changelog-Fixed: connectd no longer crashes when peers reconnect.
whitslack
added a commit
to whitslack/lightning
that referenced
this issue
Jun 1, 2022
`peer_reconnected` was freeing a `struct peer_reconnected` instance while a pointer to that instance was registered to be passed as an argument to the `retry_peer_connected` callback function. This caused a use-after-free crash when `retry_peer_connected` attempted to reparent the instance to the temporary context. Instead, never have `peer_reconnected` free a `struct peer_reconnected` instance, and only ever allow such an instance to be freed after the `retry_peer_connected` callback has finished with it. To ensure that the instance is freed even if the connection is closed before the callback can be invoked, parent the instance to the connection rather than to the daemon. Absent the need to free `struct peer_reconnected` instances outside of the `retry_peer_connected` callback, there is no use for the `reconnected` hashtable, so remove it as well. See: ElementsProject#5282 (comment) Fixes: ElementsProject#5282 Fixes: ElementsProject#5284 Changelog-Fixed: connectd no longer crashes when peers reconnect.
rustyrussell
pushed a commit
to rustyrussell/lightning
that referenced
this issue
Jun 20, 2022
`peer_reconnected` was freeing a `struct peer_reconnected` instance while a pointer to that instance was registered to be passed as an argument to the `retry_peer_connected` callback function. This caused a use-after-free crash when `retry_peer_connected` attempted to reparent the instance to the temporary context. Instead, never have `peer_reconnected` free a `struct peer_reconnected` instance, and only ever allow such an instance to be freed after the `retry_peer_connected` callback has finished with it. To ensure that the instance is freed even if the connection is closed before the callback can be invoked, parent the instance to the connection rather than to the daemon. Absent the need to free `struct peer_reconnected` instances outside of the `retry_peer_connected` callback, there is no use for the `reconnected` hashtable, so remove it as well. See: ElementsProject#5282 (comment) Fixes: ElementsProject#5282 Fixes: ElementsProject#5284 Changelog-Fixed: connectd no longer crashes when peers reconnect.
|
This is fixed for me in v0.11.2. |
|
Duplicates #5282 |
rustyrussell
pushed a commit
that referenced
this issue
Jun 28, 2022
`peer_reconnected` was freeing a `struct peer_reconnected` instance while a pointer to that instance was registered to be passed as an argument to the `retry_peer_connected` callback function. This caused a use-after-free crash when `retry_peer_connected` attempted to reparent the instance to the temporary context. Instead, never have `peer_reconnected` free a `struct peer_reconnected` instance, and only ever allow such an instance to be freed after the `retry_peer_connected` callback has finished with it. To ensure that the instance is freed even if the connection is closed before the callback can be invoked, parent the instance to the connection rather than to the daemon. Absent the need to free `struct peer_reconnected` instances outside of the `retry_peer_connected` callback, there is no use for the `reconnected` hashtable, so remove it as well. See: #5282 (comment) Fixes: #5282 Fixes: #5284 Changelog-Fixed: connectd no longer crashes when peers reconnect.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue and Steps to Reproduce
Might be similar to #5282
Flow of events:
Compacting backup:
One force close, that probably shouldn't have happened:
Crash:
Backtrace from syslog:
getinfooutput{
"id": "REDACTED",
"alias": "REDACTED",
"color": "037e27",
"num_peers": XX,
"num_pending_channels": 0,
"num_active_channels": XX,
"num_inactive_channels": X,
"address": [
{
"type": "ipv6",
"address": "XXXX",
"port": 9735
},
{
"type": "torv3",
"address": "XXXXX",
"port": 9735
}
],
"binding": [
{
"type": "ipv6",
"address": "::",
"port": 9735
},
{
"type": "ipv4",
"address": "0.0.0.0",
"port": 9735
}
],
"version": "0.11.1",
"blockheight": 737466,
"network": "bitcoin",
"msatoshi_fees_collected": X,
"fees_collected_msat": "XXXX",
"lightning-dir": "/home/lightning/.lightning/bitcoin",
"our_features": {
"init": "282a69a2",
"node": "800000282a69a2",
"channel": "",
"invoice": "02000020024100"
}
}
The text was updated successfully, but these errors were encountered: