05:56:24 Maybe I am dumb. HackerOne says "This report has been disclosed." but I don't see any details, can't seem to read anything from the conversation, hardly know anything more now than what this was about, on a conceptual level. Is this already "disclosure"? Is there a second level of "disclosure" with more details? 07:17:50 https://github.com/monero-project/monero/pull/9765 was the PR that fixed that vulnerability 07:19:46 TLDR it was possible to make monerod allocate too much RAM while serving many RPC requests in parallel 10:41:13 rbrunner7: it's a limited disclosure, the issue submitter requested it this way 11:25:39 sech1 thats a different one 12:03:03 At my understand of it, no, there is no second level of disclosure provided by H1. 12:03:16 also yeah ofrnxmr is right. sech1 this is a different vulnerability 12:04:54 i hope whoever find this one in particular will disclose it in details 19:13:11

These DOS issues are why I think it is so important to develop RPC fuzzing harnesses for monerod. I’m soliciting quotes from different firms currently for MAGIC. If anyone knows someone willing and able to write c++ fuzzing harnesses compatible with afl++ please reach out. 19:52:15 From my analysis, the network code, especially the epee section, would better benefit from an extended peer review, and some sections should be rewritten entirely. 19:53:07 Fuzzing can be considered next. 20:00:38 the list of things that could do with a refactor is quite large ... :p 20:15:09 maybe even get rid of epee entirely? 20:15:11 I noticed that the recent release revealed that you made two disclosure, was Cuprate a catalyst of your findings ? 20:17:51 one of them yes, the other no but I used Cuprate crates to make PoC for both. 20:46:09 we do have some fuzz tests: https://github.com/monero-project/monero/tree/master/tests/fuzz 21:48:05 we can't sir 21:48:17 be more precise 22:20:04 lordoftheepee.png 22:20:53 LMAO