Project

General

Profile

Bug #10483

Possible segmentation fault in WebSession during application creation

Added by Steven Köhler 17 days ago. Updated about 24 hours ago.

Status:
Resolved
Priority:
Normal
Target version:
Start date:
06/12/2022
Due date:
% Done:

100%

Estimated time:

Description

While tracing an issue in my application I somehow managed to get it in an invalid state during application construction and thus caused an exception, which was not caught in the constructor, as it was completely unexpected. Since I anticipated such a case might occur I added some error handling in the function that creates the application, and that is passed to WServer::addEntryPoint, which looks something like this:

auto createFn = [](/* params */) {
  std::unique_ptr<MyApp> app;
  try {
    app = std::make_unique<MyApp>(/* params */);
    return app
  } catch (...) {
    /* error handling */
  }
  return app; // = nullptr at this point
}

It seemed to be a reasonable idea not to relay an unhandled exception to Wt, but to indicate a failed construction with a nullptr, which is the only valid return value for createFn in case the construction failed. Or so I thought... It turned out, that this causes a segmentation fault in WebSession::start, which kills the whole server, since Wt lacks a null check there. Wt's whole application creation is wrapped in a try-catch-block, but since segmentation faults cannot be caught that way, it just crashes despite the intended error handling.

bool WebSession::start(WebResponse *response) {
  try {
    app_ = controller_->doCreateApplication(this).release();
    if (!app_->internalPathValid_)
      if (response->responseType() == WebResponse::ResponseType::Page)
    response->setStatus(404);
  } catch (std::exception& e) {
  ...

It is an easy fix in my application to just remove my custom error handling or rethrow the exception, but it seems to be kind of counter-intuitive to relay an unhandled exception to prevent a server crash.

Therefor I suggest some additional error handling in WebSession::start to handle nullptr, especially since it is not documented that a nullptr must not be returned and since I can image some cases that lead to a returned nullptr. In any case it should never be possible to kill the whole server like this, but instead produce an HTTP 500 error like when unhandled exceptions occur.

I already implemented the proposed fix an created a pull request: https://github.com/emweb/wt/pull/193.

#1

Updated by Roel Standaert 6 days ago

  • Status changed from New to InProgress
  • Assignee set to Roel Standaert
  • Target version set to 4.8.0
#2

Updated by Roel Standaert 6 days ago

  • Status changed from InProgress to Resolved
  • Assignee changed from Roel Standaert to Steven Köhler

Thanks!

#3

Updated by Roel Standaert 1 day ago

  • Target version changed from 4.8.0 to 4.7.3
#4

Updated by Roel Standaert about 24 hours ago

  • % Done changed from 0 to 100

Also available in: Atom PDF