Zombie connection after lightningd ignores `connectd_peer_spoke`
Maintainer thường phản hồi trong vòng 2 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 55/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- c
- Lĩnh vực
- networking
Hướng nghiên cứu
Bắt đầu với phần xử lý liên quan trong connectd/multiplex.c và lightningd/peer_control.c, đặc biệt là sáu đường đi mà handle_peer_spoke không phản hồi. Theo dõi thông báo connectd_peer_no_subd được đề xuất qua cả hai thành phần; hoàn thành khi việc khởi động hoặc tra cứu subdaemon thất bại giải phóng subd tương ứng và connectd tiếp tục đọc các thông báo từ peer.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
When connectd reads a peer message whose channel_id has no attached subd, it creates a subd with conn == NULL and sends connectd_peer_spoke to lightningd, asking it to start up a subdaemon and respond with connectd_peer_connect_subd and the file descriptor that should be assigned to conn.
While connectd is waiting for lightningd's response, it stops reading all messages from the peer:
The io_wait at the end is only released when either lightningd responds, or when CLN needs to send a message to that peer (e.g., gossip flush). If neither happens, the connection becomes a zombie and all peer messages are ignored until eventually the ping timeout expires and the connection is dropped.
There are currently six situations where lightningd's handle_peer_spoke never responds:
-
The peer sends an
errorfor its first message (e.g., data loss recovery).
https://github.com/ElementsProject/lightning/blob/ae53e8775e57ddf8debfd6fc7b8e3cb5e2c93dc6/lightningd/peer_control.c#L2067-L2072 -
channeld dies from a bug or protocol violation, and the peer sends another message for that channel before lightningd recognizes the channeld died. An alternative (benign) way to trigger this is when
lightningdhas already created the requested subdaemon butconnectdhasn't processed it yet.
https://github.com/ElementsProject/lightning/blob/ae53e8775e57ddf8debfd6fc7b8e3cb5e2c93dc6/lightningd/peer_control.c#L2074-L2081 -
The peer attempts a
channel_reestablishwhile the node is shutting down.
https://github.com/ElementsProject/lightning/blob/ae53e8775e57ddf8debfd6fc7b8e3cb5e2c93dc6/lightningd/peer_control.c#L2083-L2097 -
The peer sends a message after channeld was killed without a status message (e.g., OOM).
https://github.com/ElementsProject/lightning/blob/ae53e8775e57ddf8debfd6fc7b8e3cb5e2c93dc6/lightningd/peer_control.c#L2100-L2109 -
openingd fails to spawn (e.g., fd limit reached).
https://github.com/ElementsProject/lightning/blob/ae53e8775e57ddf8debfd6fc7b8e3cb5e2c93dc6/lightningd/peer_control.c#L2143-L2145 -
dualopend fails to spawn (e.g., fd limit reached).
https://github.com/ElementsProject/lightning/blob/ae53e8775e57ddf8debfd6fc7b8e3cb5e2c93dc6/lightningd/peer_control.c#L2163-L2165
Suggested fix
Add a new message connectd_peer_no_subd that lightningd can respond with when handle_peer_spoke fails in the above situations. Then connectd knows to free the matching subd and continue reading from the connection.
Discovery
This bug was discovered while fuzzing CLN with smite. Smite would send a channel_ready message with an incorrect channel_id, causing channeld to exit. Then smite would send another channel message, which would trigger the Situation 2 race condition and zombify the connection.
- Ngôn ngữ chính
- C
- Star
- 3.1k
- Fork
- 1k
- Merge trung bình
- 4 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 45
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ElementsProject/lightning
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
ElementsProject/lightning#9593 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ElementsProject/lightning#9322 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ElementsProject/lightning#9206 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ElementsProject/lightning#9187 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
-
QA
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
ElementsProject/lightning#9117 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của ElementsProject/lightning
Issue tương tự
-
Linux notifications: the default action's ' ' label shows as a blank button in xfce4-notifydĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
kovidgoyal/kitty#10625 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Feature Status: Needs Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
Maintainer thường phản hồi trong vòng 1 ngày
-
docs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
本機相簿無法上傳webm檔案Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
xiaojieonly/Ehviewer_CN_SXJ#2893 ·