Overview

Most of my time this week was spent on determining the severity of the memory bug in the gossip daemon and following up on received feedback. In addition, I also finally started working on the fuzzer for connectd-channeld interface.

Goals accomplished

  • Started work on the channeld-connectd interface fuzzer: The peer_in() function in channeld/channeld.c handles connectd messages like UPDATE_ADD_HTLC and REVOKE_AND_ACK. Due to its stateful design, creating a stateful fuzz test for it has been a long-term plan of mine. I finally began this week and have completed a substantial portion of the initial setup. As this is a complex target, it will require considerable time to reach a mergeable state, but the foundational work is now complete.

  • Started work on a handle_commit_signed fuzzer: Last week, while investigating a crash in the initial_channel fuzzer, I traced its callers to openingd/dualopend.c. To reproduce the bug from a higher level, this meant I needed to target a handler within that file.

    I started by attempting to add a target for handle_commit_signed() but soon realized that a simple fuzzer, like the one for open_channel messages, would be insufficient for the task. I’ve paused work on this approach for now and plan to discuss a better strategy with Matt first.

  • Addressed received feedback: This week, I addressed upstream feedback for several targets, including open_channel and wireaddr_internal. While the work on these is not yet finished, I’m making steady progress toward completion. While working on the wireaddr_internal feedback, I discovered a new UBSan error in parse_wireaddr()/fmt_wireaddr(). I have discussed a potential fix with Matt, but the final solution is still under consideration.

  • Mailed the vulnerability report: When addressing feedback on the fundee_channel target I had previously pushed upstream, I encountered a new input set that caused a crash in CLN. I informed Matt, and after his investigation, we confirmed that this was indeed a real vulnerability. Following that, the next step was to draft a report for the Core Lightning security mailing list. I wrote the draft report and sent it to Matt last week and got feedback on it, which I incorporated in the report and sent to CLN’s security mailing list this week.

  • Created a program to trigger the gossipd-connectd vulnerability: This week, one of my goals was to assess the severity of a vulnerability I had discovered in CCAN’s integer map function, which was found by fuzzing the gossipd-connectd interface. In my meeting with Matt on Monday, he concluded that the vulnerability was not severe. He explained that CLN nodes have a hard limit on the number of channel_announcement messages they store, which would prevent memory usage from growing too large. Based on this feedback, I abandoned my plan to simulate an attack using that message type.

    However, while improving the fuzz target, I encountered a separate memory leak triggered by sending channel_update messages. Matt was initially skeptical that this was a serious issue, but I decided to investigate further. I modified an attack program he had previously given me, changing its payload to a flood of malicious channel_update messages.

    My hypothesis was correct. The program successfully triggered unbounded memory usage in both connectd and gossipd. This confirms a significant Denial of Service (DoS) vulnerability. Even if its root cause is different from what my fuzzer originally found, this investigation has uncovered a critical issue in the code.

  • Finished revisiting targets: I have finished revisiting my existing fuzz targets to increase their code coverage, and I believe they are all now in a mergeable state.

    The final remaining task is to discuss the target for gossmap_manage operations with Matt. We need to decide if this target is useful enough to improve, as there is already an existing fuzzer for the gossip daemon that covers these same operations. His feedback will determine whether I spend more time increasing this target’s coverage or not.

Next week’s goals

A lot of the work that I plan to do next week depends on my next meeting with Matt, since there’s a lot of stuff to evaluate. With that being said, here are some of my immediate goals for the upcoming week:

  • Finish the target for channeld-connectd interface: I’ve laid the foundation for this new target and will continue working on it next week. However, I need to determine if this target is necessary at all, as its purpose may overlap with the full-channel target I completed last week. That target already provides stateful testing for the HTLC state machine, which might make this new one redundant. While I aim to make progress, I first need to clarify if this work is worth pursuing.

  • Try triggering the initial_channel bug from the dual-channel handlers: I have already attempted this by adding a new commit_signed target to the fuzz suite. However, as I mentioned previously, I have paused my work on it for now. My plan is to first discuss a better approach with Matt. I now believe that the best solution, after all, would be to make the open_channel2 fuzzer stateful. I intend to re-examine that plan on Monday before speaking with him.

  • Reach a conclusion on the gossipd-connectd vulnerability: I believe I’ve completed most of the work required on my end, and that we’re close to reaching a conclusion on the nature and severity of this bug. In his latest feedback, Matt asked me to further evaluate the attack program’s behavior and to generate a memory profile to identify the source of the issue. I was able to complete the first task, but I could not generate the memory profile. I will inform Matt of this and ask if he can handle that part of the plan.

  • Reach a conclusion on the full-channel bug: I briefly discussed this target with Matt in our last meeting, but a verbal explanation was not enough for him to understand the situation due to its complexity. We decided to defer the discussion until I push the target upstream, which will allow him to review the code directly for a complete picture.

    My original plan was to push the target this week. I couldn’t, however, because there is already a backlog of other targets upstream waiting for review. Given that little time is left in the project and I believe this issue is serious, I want to ensure we have ample time to discuss it. Therefore, I now plan to push this target upstream first thing on Monday to prioritize it.

  • Rework the wireaddr bug fix: As I’ve mentioned, addressing the feedback on the wireaddr_internal target led to the discovery of another bug in fmt_wireaddr(). I have devised a minimal fix that handles both of these issues and have communicated it to Matt. I am now waiting for his approval to incorporate this solution into the fix that has already been pushed upstream.

Challenges

As I mentioned last week, my primary challenge is balancing my internship responsibilities with my academic workload. I’ve been managing my time by working one day over the weekend, but I feel that my productivity during these hours isn’t as high as it was during my vacation. This is likely because it was the first week of the new semester, and the adjustment has been significant. With the internship nearing its end, this is a concern for me. However, instead of dwelling on the past week, my focus is now on adapting more effectively and improving my productivity in the week ahead.

Today marks the end of my 11th week, with only two weeks remaining in the internship. I’m thrilled about finding a serious DoS vector in the codebase and am hopeful that the potential vulnerability in the gossip state machine proves to be significant as well. Discovering one more serious issue, for a total of three, would be a very satisfying outcome for my internship to me. With the limited time left, my strategy is to focus on reaching conclusions on the potential bugs I’ve already found, rather than pursuing new targets.

Till next time,

Chandra.

<
Previous Post
SoB: Week 10
>
Next Post
SoB: Week 12 and 13