httpd_ssl_start potential memory leak (IDFGH-12519)

[sascha-jopen]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

master

Espressif SoC revision.

ESP32

Operating System used.

Linux

How did you build your project?

CLion IDE

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-PICO-KIT

Power Supply used.

USB

What is the expected behavior?

When httpd_ssl_start() is invoked from a user application and an error occurs during httpd_start() within that function, all allocated memory of httpd_ssl_start should be freed to prevent memory leaks.

What is the actual behavior?

In

esp-idf/components/esp_https_server/src/https_server.c

Line 383 in be06a6f

httpd_ssl_ctx_t *ssl_ctx = calloc(1, sizeof(httpd_ssl_ctx_t));

memory for a new ssl context is allocated. If starting the underlying http server in

esp-idf/components/esp_https_server/src/https_server.c

Line 413 in be06a6f

ret = httpd_start(&handle, &config->httpd);

fails, the ssl context is not freed. Instead the function returns in

esp-idf/components/esp_https_server/src/https_server.c

Line 414 in be06a6f

if (ret != ESP_OK) return ret;

without any cleanup. The cleanup is not done in

esp-idf/components/esp_http_server/src/httpd_main.c

Line 478 in be06a6f

esp_err_t httpd_start(httpd_handle_t *handle, const httpd_config_t *config)

either.

Steps to reproduce.

I haven't checked the issue on an ESP32 device but only with code review. However, calling httpd_ssl_start with config->max_open_sockets = CONFIG_LWIP_MAX_SOCKETS or config->max_open_sockets = 15, depending on the build, should trigger the memory leak.

Debug Logs.

No response

More Information.

On a first glance

esp-idf/components/esp_https_server/src/https_server.c

Line 388 in be06a6f

ret = create_secure_context(config, &ssl_ctx);

looks like producing a memory leak when create_secure_context() fails, too. This is actually not true as the memory is freed in

esp-idf/components/esp_https_server/src/https_server.c

Line 369 in be06a6f

free(*ssl_ctx);

in case of an error. However, it might be more readable to move freeing the memory in case of an error to the caller, where the memory was allocated in the first place.