Issue and Steps to Reproduce
sendpay with a route whose per-hop payloads do not fit the 1300-byte onion crashes lightningd with SIGSEGV.
In send_payment (lightningd/pay.c), the result of create_onionpacket() is passed along without a NULL check:
https://github.com/ElementsProject/lightning/blob/d05815f5f/lightningd/pay.c#L1261
create_onionpacket() returns NULL when sphinx_path_payloads_size(sp) > fixed_size (common/sphinx.c). send_onion() then calls serialize_onionpacket(), which dereferences m->routinginfo and segfaults. The sendonion RPC path checks the same call and fails gracefully ("Could not create onion packet", pay.c#L2441); the sendpay path does not.
Observed in production (v26.04.1 plus local askrene patches; the affected code is unchanged on current master): a rebalancing plugin submitted a 25-hop route, lightningd logged "Sending 818536msat over 25 hops to deliver 818475msat" and crashed 114ms later. We have hit the identical backtrace with 26-hop routes before; 21-hop routes still fit, the limit being payload bytes rather than hop count.
FATAL SIGNAL 11 (version v26.04.1)
common/sphinx.c:187 (serialize_onionpacket)
lightningd/pay.c:785 (send_onion)
lightningd/pay.c:1137 (send_payment_core)
lightningd/pay.c:1259 (send_payment)
lightningd/pay.c:1630 (json_sendpay)
lightningd/jsonrpc.c:771 (command_exec)
Repro: on regtest with one live channel, call sendpay with a fabricated route of ~25 hops (repeat a hop; only the first hop needs to be a usable channel -- the crash happens while building the onion, before anything is sent).
Expected behavior
sendpay returns an RPC error, as the sendonion path already does, and the daemon stays up.
Issue and Steps to Reproduce
sendpaywith a route whose per-hop payloads do not fit the 1300-byte onion crashes lightningd with SIGSEGV.In
send_payment(lightningd/pay.c), the result ofcreate_onionpacket()is passed along without a NULL check:https://github.com/ElementsProject/lightning/blob/d05815f5f/lightningd/pay.c#L1261
create_onionpacket()returns NULL whensphinx_path_payloads_size(sp) > fixed_size(common/sphinx.c).send_onion()then callsserialize_onionpacket(), which dereferencesm->routinginfoand segfaults. ThesendonionRPC path checks the same call and fails gracefully ("Could not create onion packet", pay.c#L2441); thesendpaypath does not.Observed in production (v26.04.1 plus local askrene patches; the affected code is unchanged on current master): a rebalancing plugin submitted a 25-hop route, lightningd logged "Sending 818536msat over 25 hops to deliver 818475msat" and crashed 114ms later. We have hit the identical backtrace with 26-hop routes before; 21-hop routes still fit, the limit being payload bytes rather than hop count.
Repro: on regtest with one live channel, call
sendpaywith a fabricated route of ~25 hops (repeat a hop; only the first hop needs to be a usable channel -- the crash happens while building the onion, before anything is sent).Expected behavior
sendpayreturns an RPC error, as thesendonionpath already does, and the daemon stays up.