[bug]: BOLT 11 Compliance: Invoice description field not validated as UTF-8

[erickcestari]

Background

After doing some differential fuzzing between rust-lightining and LND using bitcoinfuzz I noticed that LND currently accepts Lightning invoices with invalid UTF-8 in the description field (d), violating BOLT 11 specification requirements.

BOLT 11 Requirements:

• d field "Short description of purpose of payment (UTF-8)"
• Writer "MUST set d to a valid UTF-8 string"

Current Behavior: The parseDescription function converts bech32 data to string without UTF-8 validation, allowing invalid byte sequences.

Expected Behavior: Reject invoices with non-UTF-8 description fields per spec.

Impact:

• Spec non-compliance
• Potential interoperability issues with other Lightning implementations
• Display problems in wallets/UIs

Proposed Fix: Add utf8.Valid() check in parseDescription before string conversion.

if !utf8.Valid(base256Data) {
    return nil, fmt.Errorf("description is not valid UTF-8")
}

Example invoice with invalid description UTF-8 bytes:

lnbc100n1pllllllpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdz823jhxapqv3jhxcmjd9c8g6t0dcs924zx95uzqamfw35zq6twweskc6tyyp38jar9wvs0llsnp4q0n326hr8v9zprg8gsvezcch06gfaqqhde2aj730yg0durunfhv669qrsgquuwsa0vmqyngdnj3j2sz0hc29eaq0sypz2lpr8v2aa0csjufcw9j3hzp6sfzzuu6jz7gzs22sw0msxaq7uc0jzp7usmg2dsa6cxahrqpjdwkzz

[MPins]

@erickcestari and @saubyk I was able to reproduce the behaviour (IMO not an issue) locally using my regtest environment by modifying a unit test, as shown below.

To simulate the problem, I crafted an invoice that includes non-UTF-8 characters in the description field:

lnbcrt11p59fzc9pp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqsp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdqh23jhxa8ldehkugz423rz6wqgy6rtlmzsjsfc6qh9nks7uvrv7p9wkzsv52esd47ch9d2tluy40yu4hrm9ffg0srguz8axfaduqatmpnpuzy26xvu7yerjq6txffumsqvj08cw

When using lncli, the behaviour is somewhat hidden:

alice:/# lncli decodepayreq lnbcrt11p59fzc9pp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqsp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdqh23jhxa8ldehkugz423rz6wqgy6rtlmzsjsfc6qh9nks7uvrv7p9wkzsv52esd47ch9d2tluy40yu4hrm9ffg0srguz8axfaduqatmpnpuzy26xvu7yerjq6txffumsqvj08cw
[lncli] rpc error: code = Internal desc = grpc: error while marshaling: string field contains invalid UTF-8

To catch the issue during unit testing, I added the invoice above to the TestExtractIntentFromSendRequest unit test and introduced a test case that uses the invoice, marking it as valid.

// TestExtractIntentFromSendRequest verifies that extractIntentFromSendRequest
// correctly translates a SendPaymentRequest from an RPC client into a
// LightningPayment intent.
func TestExtractIntentFromSendRequest(t *testing.T) {
.
.
.
	const paymentReqNonUTF8 = "lnbcrt11p59fzc9pp5qqqsyqcyq5rqwzqfqqqsyqcy" +
		"q5rqwzqfqqqsyqcyq5rqwzqfqypqsp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqw" +
		"zqfqqqsyqcyq5rqwzqfqypqdqh23jhxa8ldehkugz423rz6wqgy6rtlmzsjs" +
		"fc6qh9nks7uvrv7p9wkzsv52esd47ch9d2tluy40yu4hrm9ffg0srguz8axf" +
		"aduqatmpnpuzy26xvu7yerjq6txffumsqvj08cw"
.
.
.
	testCases := []extractIntentTestCase{
.
.
.


		{
			name: "Invoice with Non UTF-8 description",
			backend: &RouterBackend{
				ShouldSetExpEndorsement: func() bool {
					return false
				},
				ActiveNetParams:  &chaincfg.RegressionNetParams,
				MaxTotalTimelock: 1000,
				Clock:            mockClock,
			},
			sendReq: &SendPaymentRequest{
				PaymentRequest: paymentReqNonUTF8,
				CltvLimit:      22,
			},
			valid: true,
		},
.
.
.
}

The result shows that the testcase was executed with success:

Running tool: /usr/local/go/bin/go test -timeout 30s -tags autopilotrpc chainrpc dev invoicesrpc neutrinorpc peersrpc signrpc walletrpc watchtowerrpc -run ^TestExtractIntentFromSendRequest$ github.com/lightningnetwork/lnd/lnrpc/routerrpc

=== RUN   TestExtractIntentFromSendRequest
.
.
.
--- PASS: TestExtractIntentFromSendRequest/Invoice_with_Non_UTF-8_description (0.00s)
.
.
.
PASS
ok      github.com/lightningnetwork/lnd/lnrpc/routerrpc 0.022s

[MPins]

@erickcestari I see your point, but IMO it's not an issue because the BOLT requirements mentioned above are writer-side constraints.

[erickcestari]

@erickcestari I see your point, but IMO it's not an issue because the BOLT requirements mentioned above are writer-side constraints.

In this case, I don't think those constraints are only on the writer side, since the definition of the description (d) specifies that the value should be UTF-8. So rejecting invoices where the description is not valid UTF-8 should be done by readers as well. Likely other field types too.

d (13): data_length variable. Short description of purpose of payment (UTF-8), e.g. '1 cup of coffee' or 'ナンセンス 1杯'

[MPins]

@erickcestari I see your point, but IMO it's not an issue because the BOLT requirements mentioned above are writer-side constraints.

In this case, I don't think those constraints are only on the writer side, since the definition of the description (d) specifies that the value should be UTF-8. So rejecting invoices where the description is not valid UTF-8 should be done by readers as well. Likely other field types too.

d (13): data_length variable. Short description of purpose of payment (UTF-8), e.g. '1 cup of coffee' or 'ナンセンス 1杯'

Besides that the spec say that the reader MUST fail the payment if neither a d field nor a h field is present, or if both are present.

So I agree with you, in this case we should consider that d is present only if it is a valid one 👍 .

[MPins]

@saubyk I think we can consider the triage was done and it is an issue.