Summary

memory_config_patch (PATCH /api/memory/config) read config.toml, parsed it as a toml::Value, then did:

let memory_tbl = root
    .entry("memory")
    .or_insert_with(|| toml::Value::Table(toml::map::Map::new()))
    .as_table_mut()
    .unwrap();                       // <- panics

and the same for proactive_memory. entry(..).or_insert_with only inserts the default table when the key is absent. If config.toml already holds a scalar at that key — e.g. an operator hand-edited memory = 5 or proactive_memory = "x" — entry() returns the existing non-table value, as_table_mut() returns None, and the unwrap() panics.

axum isolates the panic to the request task (the daemon survives and returns 500), so the blast radius is one failed admin PATCH, and the trigger requires a pre-existing malformed config on disk (operator-controlled, not attacker-controlled) — hence low severity. But the operator gets an opaque 500 + a panic in the logs instead of a useful message.

The top-level table.as_table_mut().unwrap() (the document root) is left as-is: a valid TOML document root is always a table.

Fix

Both as_table_mut() sites now return a clear 400 Bad Request (config.toml has a non-table [memory] entry; expected a table) instead of panicking.

Tests

Adds two #[tokio::test] cases to memory_routes_integration.rs:

• patch_memory_config_with_non_table_memory_entry_is_graceful — seeds memory = 5, asserts 400 + error body.
• patch_memory_config_with_non_table_proactive_memory_entry_is_graceful — seeds proactive_memory = "oops", asserts 400 + error body.

Verification

This host has no native Rust toolchain and no working container runtime, so local cargo verification was not possible — CI is the gate. Reviewers / CI: cargo test -p librefang-api.

Scope

One of several independent findings from a repo audit; filed as its own PR per the one-PR-one-domain policy.