ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-04 11:55:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2941 from XRPLF/blog-update

Browse Source 
Add clarification on the VDR blog post
This commit is contained in:
Amarantha Kulkarni
2025-01-10 12:15:44 -08:00
committed by GitHub
parent a1aed005ce 53575037c3
commit dd0c42a93c
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
blog/2025/vulnerabilitydisclosurereport-bug-nov2024.md
View File

@@ -54,7 +54,7 @@ The original investigation believed that the spread would be contained to only t
### Triggering Transaction
On 25 November, 3 identical PaymentChannelClaim transactions - other than the sequence number - were submitted that referenced a RippleState (trustline) ledger object (instead of a PayChannel object, as expected). These all failed successfully, without crashing the ledger. Then the same account submitted a TrustSet for that RippleState object, and submitted the same PaymentChannelClaim transaction again. The TrustSet transaction made the RippleState ledger object more likely to be in the cache, which then crashed any node that had it in its cache. One of the [transactions](https://livenet.xrpl.org/transactions/5729C3A94A9950419292649D9E649F0BDC9D86499EE5A0CDB009DEA963DAF727) can be seen in ledger [92346897](https://livenet.xrpl.org/ledgers/92346897).
On 25 November, 3 identical PaymentChannelClaim transactions - other than the sequence number - were submitted that referenced a RippleState (trustline) ledger object (instead of a PayChannel object, as expected). These all failed successfully, without crashing the ledger. Then the same account submitted a TrustSet for that RippleState object, and submitted the same PaymentChannelClaim transaction again. The TrustSet transaction made the RippleState ledger object more likely to be in the cache, which then allowed the following PaymentChannelClaim transaction to crash any node that had it in its cache. One of the [transactions](https://livenet.xrpl.org/transactions/5729C3A94A9950419292649D9E649F0BDC9D86499EE5A0CDB009DEA963DAF727) can be seen in ledger [92346897](https://livenet.xrpl.org/ledgers/92346897).
The current hypothesis for the spread is that some nodes had flushed that RippleState ledger object out of their cache and were thus able to process the transaction and propagate it to other nodes. This would also explain why there were still some crashes later when nodes started catching up again, and why the crashes eventually did stop (after the crash, a node wouldn’t have its cache populated, so it would be correctly handle the invalid PaymentChannelClaim).