Lighttpd

Where exactly is the DoS when crashing a process that only handles the single request that triggered the crash?

If run from xinetd, then stdin is a socket, not a pipe.
If run from nc (netcat), stdin and stdout pipes will be independent pipes.

I'll take a closer look at the scenario you have presented, but my initial quick review suggests that this can not be triggered remotely from xinetd.
Thank you for the report and for the test scenario.

gstrauss wrote in #note-2:

If run from xinetd, then stdin is a socket, not a pipe.
If run from nc (netcat), stdin and stdout pipes will be independent pipes.

I'll take a closer look at the scenario you have presented, but my initial quick review suggests that this can not be triggered remotely from xinetd.
Thank you for the report and for the test scenario.

Indeed, he cannot be reproduced on xinetd.I mean there's a chance he'll be in a scene like 'xinetd'.

stbuehler wrote in #note-1:

Where exactly is the DoS when crashing a process that only handles the single request that triggered the crash?

When the output pipe 'epoll FDEVENT_HUP' is triggered again after 'http-con' is cleared due to http parsing error, 'server_oneshot_handle_fdevent' is called, in which 'con->fdn == NULL'

Indeed, he cannot be reproduced on xinetd.I mean there's a chance he'll be in a scene like 'xinetd'.

No, no there is not. The bug you found is in lighttpd's handling of lighttpd -1 with pipes, e.g. with nc (netcat). This will not occur with xinetd. No chance.

The bug occurs with lighttpd -1, which by definition is one-shot. This does not cause a denial of service, since the next independent request will result in a new instance of lighttpd.

What you have found is a bug that causes lighttpd to crash in a very specific use case, which is not common. Still, lighttpd should detect this situation and should not crash.

Quick patch should work around this issue. However, I am still reviewing to see if there are better solutions.

--- a/src/server.c
+++ b/src/server.c
@@ -444,7 +444,7 @@ static handler_t server_oneshot_handle_fdevent(void *context, int revents) {
     fdevent_fdnode_event_set(con->srv->ev, oneshot_fdn, n);

     fdnode * const fdn = con->fdn; /* fdn->ctx == con */
-    handler_t rc = ((fdevent_handler)NULL != fdn->handler)
+    handler_t rc = (fdn && (fdevent_handler)NULL != fdn->handler)
       ? (*fdn->handler)(con, revents)
       : HANDLER_FINISHED;

good work, 'lighttpd -1' is usually used in resource-limited spaces, and will use more resources anyway. Is it possible for me to get a cve number

I do not believe this is a bug in a real-world use case. As such, I do not believe this qualifies for a CVE.

As I mentioned above, this bug occurs with pipes on stdin, and the bug does not occur with sockets. The bug does not occur with lighttpd -1 from xinetd.

As I mentioned above, the bug is not a denial of service, since lighttpd -1 handles one connection in one-shot mode. The next independent request will result in a new instance of lighttpd -1.

Please justify why you think a CVE is appropriate for a bug which is not a common use of lighttpd (lighttpd -1 on a pipe) and has no real effect besides not sending an HTTP response to the request after the input pipe is quickly closed.

Okay, I get it, looking forward to the next collaboration

Thank you for your bug report. The bug has been determined to be low-impact and not a denial of service.

.

Reposting generic info I have posted elsewhere in the past:

Not all bugs are vulnerabilities. Vulnerabilities are a subset of bugs.

From the official CVE site:
https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryVulnerability
https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_7-1_what_is_a_vulnerability

More specifically, a bug must violate security policy and have an impact.