rust-lightning

This commit fixes a bug in a small helper crate called `possiblyrandom` used by the Lightning Dev Kit. The crate was supposed to return real random bytes on normal operating systems, but due to a Cargo.toml misconfiguration it was silently returning zeros unless an explicit feature flag was turned on. Randomness is important for cryptographic operations; using predictable zeros could weaken security in places that expect random input. The patch makes the code actually call the system's random source on supported platforms.

This commit fixes a minor denial-of-service issue where a malicious peer could send very long text strings inside Lightning network messages (errors, warnings, transaction aborts). Those strings were written to log files without any length limit or consistent cleanup, so an attacker could fill up disk space or make logs hard to read. The patch caps logged peer message strings at 512 characters and applies the project's usual untrusted-string sanitization everywhere these messages are logged.

This commit fixes a remote denial-of-service bug in rust-lightning's LSPS (Lightning Service Provider Specification) code. An attacker could send a specially crafted date string from before 1970 (like "1900-01-01T00:00:00Z") in certain peer messages. The date would be accepted, and later when the software checked whether it had expired, it would panic and crash the LSP thread. The fix rejects any pre-1970 date during parsing, including when reading JSON from peers, so the dangerous value can never be created.

This commit changes how a Bitcoin Lightning invoice library exposes the payee's public key. Previously, a function called recover_payee_pub_key always returned a public key, even when mathematically recovering it from the invoice signature actually failed. Now it returns an optional value (None when recovery fails), and callers are directed to a safer accessor. The change prevents callers from silently getting a wrong or misleading key, which could matter for payment security decisions.

This commit fixes a bug in how Lightning payment parameters are built from BOLT11 invoices. Previously, the code always tried to recover the payee's public key from the invoice signature, even when the invoice already explicitly included the payee's key. Signature recovery can fail or produce the wrong key in some legitimate cases, such as when the recovery ID byte is altered. The fix makes payment routing use the explicitly included payee key when available, falling back to signature recovery only when needed. This prevents potential payment routing failures or misrouting caused by relying on recoverable signatures.

This commit fixes a denial-of-service weakness in Lightning Dev Kit's rapid gossip sync feature. A malicious or compromised RGS server could send an enormous snapshot of Lightning network data, causing a user's node to allocate so much memory that it crashes with an out-of-memory (OOM) error. The patch now rejects snapshots with absurdly high node counts and stops adding new channels once the graph grows about 10 times larger than expected. The issue was reported by Jordan Mecom of Block's Security Team.

This commit fixes a denial-of-service risk when rust-lightning reads saved data containing HashMaps. A corrupted or malicious length field could previously trick the program into reserving a huge amount of memory before it had read any actual entries. The patch now caps the initial allocation to a safe maximum based on the largest buffer size the code is willing to handle. The commit message says the affected deserialization paths were mainly ChannelManager and scorer data, with scorer data sometimes coming from a semi-trusted source.

This commit fixes a bug in the Lightning Dev Kit's LSPS2 (Just-In-Time channel) service. Previously, when a service provider abandoned a pending JIT channel open, any intercepted HTLCs (pending payment holds) waiting for that channel were left stuck in limbo instead of being properly failed backwards. The patch now drains the queued HTLCs and fails them before removing the channel state, preventing funds from being locked up and ensuring the payment sender receives a failure notification.

This is a routine internal code cleanup in the Lightning Dev Kit's payment-sending logic. It removes a now-unnecessary duplicate argument from a few private functions because the same information is already stored inside the Route object. There is no user-facing change and no security fix.

This commit makes a piece of routing data called route_params mandatory in the Lightning Dev Kit library. Previously it was optional, and the code would silently invent a dummy value if it was missing. Now it must always be provided, and old serialized routes written before version 0.0.117 will fail to load. This is a deliberate backwards-compatibility break, not a security fix, and it reduces the risk of inconsistent or missing routing information rather than introducing a vulnerability.

This commit is purely a formatting cleanup: it removes a 'skip rustfmt' marker and re-indents a function so the code is easier to read. No behavior, logic, or security properties of the payment-sending code were changed.

This commit fixes a programming bug in rust-lightning's send_to_route function. When a user supplied a payment route with no paths or an empty first path, the code tried to create a fallback 'dummy' public key using 32 bytes of data, but public keys require 33 bytes. That mismatch caused the program to panic and crash. The fix simply changes the dummy data to 33 bytes so the fallback public key is valid and the unwrap succeeds. It is a denial-of-service/crash bug, not a theft-of-funds vulnerability, because the panic aborts the operation rather than letting an attacker manipulate funds.

This commit only adds a pending changelog entry describing an API change in a previous pull request. It contains no code changes, no bug fixes, and no security-related content.

This commit fixes a mismatch in how Lightning feature flags are read from the wire. Previously, a feature set whose serialized byte length was exactly 65,535 bytes (u16::MAX) could be deserialized incorrectly because the code used a generic vector reader that may interpret the length differently. The fix reads the length as a u16 and then reads exactly that many bytes, matching the write side. The commit message says this 'shouldn't really matter in practice.'

This commit adds a safety check in the code that handles Lightning network feature flags. Feature flags are small on/off settings used when two nodes connect. The change prevents the code from accepting a feature flag position so high that it would require more than 65,535 bytes to store. Such huge positions cannot be serialized to the network format, so they are now rejected as invalid. The commit message says the issue was reported by Project Loupe.

This commit fixes a bug where a remote peer could crash a Lightning node by sending a specially chosen custom message. The crash happened because a message-routing helper assumed a sub-component would always recognize any message type matching its declared pattern, but sub-components can legitimately decline to decode some types within their pattern. The fix replaces an internal 'this should never happen' crash with a graceful 'unknown message' response.

This commit adds a new regression test for the LSPS2 (Lightning Service Provider Specification 2) feature in rust-lightning. It checks that if a node crashes and restarts, replaying the same intercepted payment event does not cause the service to accidentally queue or process the payment twice. The test ensures that after restoring saved peer state, replaying an already-seen HTLC returns no action, and the payment is still forwarded correctly once the channel is ready. There is no code fix here—only a new test to catch a past or potential duplicate-queueing bug.

This commit adds cleanup logic for a Lightning Service Provider (LSP) feature called LSPS2 Just-In-Time (JIT) channels. When a JIT channel closes, the service now deletes leftover internal tracking entries instead of keeping them forever in persistent storage. The change is framed as a state-management hygiene fix rather than an active vulnerability patch. It does not appear to fix a remotely triggerable exploit, but stale state could theoretically lead to confusion, incorrect reuse of old channel identifiers, or unbounded growth of stored data over time.

This change fixes a crash and duplicate-queue bug in the Lightning Dev Kit's LSPS2 payment queue. After a restart, previously seen intercepted HTLCs can be replayed; the old code would panic (in debug builds) or add duplicates, while the new code returns the existing payment status instead. It is a reliability/idempotency fix rather than a direct theft-of-funds vulnerability, but a panic on restart could disrupt a liquidity service.

This commit fixes a potential deadlock in how Lightning Dev Kit handles repeated lookups of the same short channel ID. When a custom UTXO lookup service returns the same in-flight future object for repeated requests, and a replacement channel announcement arrives during that lookup, the code could try to lock the same data twice. The patch detects when the pending entry refers to the already-held future state and compares messages without re-acquiring the lock, preventing deadlock while still filtering duplicate announcements.

This is a tiny one-line fix in a Lightning Service Provider feature (LSPS5). Previously, when the code had to force-save peer state for a client that was about to be removed, it saved the data but forgot to report that it had done so. The fix makes the code correctly report 'yes, we persisted.' This is a bookkeeping/reporting bug, not a direct funds-loss vulnerability, but incorrect persistence reporting could mislead callers about whether state was saved.

This one-line change fixes a bookkeeping bug in the LSPS2 (Lightning Service Provider Specification 2) service code. Previously, when the code had to force-save a peer's state before removing that peer, it performed the save but forgot to record that it had done so. Now it correctly reports 'yes, we persisted that state.' The main risk is that downstream logic relying on this flag could make wrong decisions—such as skipping a needed re-persistence, incorrectly pruning state, or reporting an inaccurate status to the caller.

This commit only fixes two typos in documentation comments ('sevice' to 'service') and slightly rewords the description of what the return value means. No code behavior changes, no security relevance.

This commit fixes a security hole in how a Bitcoin Lightning wallet talks to Electrum servers. Previously, the wallet asked a server for a specific transaction by its ID, but it did not check that the returned transaction actually matched that ID. A malicious or compromised Electrum server could send a different transaction instead, and the wallet would trust it. The fix adds a simple verification step: after receiving a transaction, the wallet recomputes its ID and rejects it if it does not match what was requested. The commit message explicitly says this prevents a malicious server from substituting an unrelated transaction and providing matching proof data.

This commit fixes a guard condition in LDK's Esplora transaction-sync code. The code tries to skip 64-byte transactions because such transactions can be abused in a known Bitcoin Merkle-tree weakness. The bug was that it measured total transaction size, which includes witness data. A transaction with witness data could be larger than 64 bytes in total size while still having a 64-byte non-witness serialization, so the guard could be bypassed. The fix uses a helper that checks the base (non-witness) size instead.