[bug]: Expiry Field Overflow in Invoice Deserialization

[erickcestari]

Background

During differential fuzzing tests on different Lightning implementations using Bitcoinfuzz, we've identified an inconsistency in how LND handles the expiry field in BOLT11 invoices compared to other implementations like C-Lightning and LDK.

When deserializing an invoice with a large expiry value, LND produces a negative expiry value due to overflow, while other implementations handle the same value correctly. This is caused by LND's use of time.Duration (int64) for storing the expiry field and the additional conversion to nanoseconds (multiplying by 1,000,000,000), which significantly reduces the effective range compared to other implementations that use uint64.

Steps to reproduce

https://github.com/bitcoinfuzz/bitcoinfuzz/actions/runs/15021579593/job/42211806963#step:33:55

Invoice that demonstrates the issue:

lnbc1qqygh9qpp5s7zqqcqpjpqqlqqqqphqqqqqqqqcqpjqqqqqqqqqqqqqqqqqqqqqxqgsqqqqqqqdqqqqqqqqqqqqqpjpqqlqqqqqqqqqqqqqqcqpjqqqqqsqqqqqqqqqqqqqqqqqnqqnqqpqqnqqqqqqqqqqqqqqqqqlqqqqqqqqqqqqqqqqqqdfrf47

Results:

LND:
HASH=878400600190400f8000006e0000000001800640000000000000000000000000;AMOUNT=0;DESCRIPTION=;RECIPIENT=02f36b27dd1d95740c66c076fb53b54991a19a525d997be3a868ff6f542242b6bd;EXPIRY=-3646508323;TIMESTAMP=4480160;ROUTING_HINTS=0;MIN_CLTV=18

C-Lightning:
HASH=878400600190400f8000006e0000000001800640000000000000000000000000;AMOUNT=0;DESCRIPTION=;RECIPIENT=02f36b27dd1d95740c66c076fb53b54991a19a525d997be3a868ff6f542242b6bd;EXPIRY=549755813888;TIMESTAMP=4480160;ROUTING_HINTS=0;MIN_CLTV=18

Note the significant difference in the EXPIRY values: LND shows a negative value (-3646508323) while C-Lightning shows 549755813888.

The underlying issue is that LND stores the expiry as a time.Duration, which is an int64, and then multiplies the decoded expiry value by 1,000,000,000 to store it as nanoseconds. This conversion significantly reduces the effective range of valid expiry values that LND can handle without overflow.

While the BOLT11 specification doesn't specify a maximum for the expiration field (it could technically be up to 639 bytes long), most implementations assume it's at most a uint64.

Proposed Solution

Consider changing LND to use uint64 for expiry fields rather than time.Duration for better compatibility with other implementations.

[morehouse]

Just want to emphasize that this isn't necessarily a bug, more of an inconsistency between implementations.

That said, making LND use uint64 for the expiry like the other implementations will be helpful for unblocking further fuzzing and finding real bugs.

[Roasbeef]

Thanks for the report!

This makes sense, we can store as a uint64, then expose a ExpiryDuration() time.Duration method or something like that. Perhaps it returns an error if the translation would trigger an underflow.

4480160 seconds is something like 50 days, which doesn't make too much sense for a normal invoice expiry. Not caught up with the latest format, but perhaps something like that would be more common for a BOLT 12 invoice?

[erickcestari]

Thanks for the report!

This makes sense, we can store as a uint64, then expose a ExpiryDuration() time.Duration method or something like that. Perhaps it returns an error if the translation would trigger an underflow.

4480160 seconds is something like 50 days, which doesn't make too much sense for a normal invoice expiry. Not caught up with the latest format, but perhaps something like that would be more common for a BOLT 12 invoice?

The timestamp 4480160 in the invoice does not cause an overflow. LND stores it using time.Time, and LDK uses Duration. Both capable of handling extremely large values.

The actual overflow occurs in the expiry field, which in this case is set to 549755813888. While most values are safely handled. Since i64::MAX / 1_000_000_000 covers nearly all typical cases. This unusually large expiry value exceeds the limit and causes an overflow in LND. Other implementations handle such values without problems.

Regarding BOLT12, the specification defines the type for offer_absolute_expiry as a tu64. I think it’s more common for an offer to have an offer_absolute_expiry set to something like one year, for example. Which can be easily handled using a u64

https://github.com/lightning/bolts/blob/master/12-offer-encoding.md?plain=1#L219