CVE-2024-53984

What it actually does

Missing call to pb_release() in pb_decode_ex() when PB_ENABLE_MALLOC, FT_POINTER fields, custom stream with unknown length, and PB_DECODE_DELIMITED flag are used together, causing memory leak on decode failure.

Why it matters to the business

Repeated exploitation can exhaust memory in long-running services, leading to service degradation or denial of service without data loss or unauthorized access.

How an attack unfolds

An attacker supplies a protobuf message over a network stream using a custom callback with unknown length and the delimited decode flag; a decode failure path skips cleanup, accumulating leaked allocations until the process terminates or becomes unresponsive.

How to fix it

Upgrade nanopb to version 0.4.9.1 or commit cad3c18ef15a663e30e3e43e3a752b66378adec1; rebuild all dependent binaries; verify PB_ENABLE_MALLOC configurations are still required.

How to confirm the fix worked

Confirm installed nanopb version is 0.4.9.1 or later; recompile test cases exercising pb_decode_ex with PB_DECODE_DELIMITED and custom streams to verify pb_release is invoked on failure.

Typical attack path

1. Identify service using nanopb with PB_ENABLE_MALLOC and FT_POINTER fields
2. Craft protobuf payload that triggers decode failure under PB_DECODE_DELIMITED
3. Send payload repeatedly via custom stream interface
4. Monitor for increasing memory usage leading to DoS

How to detect it

Review application logs for repeated decode failures involving custom streams; inspect process memory growth patterns; search build logs and dependency manifests for nanopb versions prior to 0.4.9.1.

What your security team should do

• Immediately update nanopb to 0.4.9.1 or the referenced commit across all builds
• Audit code for use of PB_ENABLE_MALLOC combined with custom streams and PB_DECODE_DELIMITED
• Add memory-leak regression tests for decode failure paths
• Monitor process memory metrics for unexpected growth in nanopb-using services