[SECURITY?] Potential overflow in libmbus manufacturer-specific data parsing

[neosys007]

Hello libmbus maintainers,

I would like to report a potential security-sensitive bug in libmbus affecting the manufacturer-specific data parsing path.

Project: libmbus
Affected file: mbus/mbus-protocol.c
Affected function: mbus_data_variable_parse()
Tested current code: tested on the then-current master branch as of 2026-03-07
Affected versions: I have confirmed this on current head; I can provide additional version verification if useful.

The issue appears to be an out-of-bounds write in the production parser path for manufacturer-specific data.

The affected destination object contains a fixed-size field:

• unsigned char data[234];
• followed by fields such as data_len, timestamp, and next

In the current manufacturer-specific / more-records-follow path, the code derives the copy count from the remaining frame size:

• record->data_len = frame->data_size - i;

and then copies that many bytes into record->data without checking whether record->data_len exceeds the capacity of data[234].

Based on this logic, if the parser reaches that branch early enough in the frame, the remaining frame data can exceed 234 bytes. In that case, the write crosses the end of record->data and overwrites adjacent live fields in the same object.

Why I believe this is a real issue:

• the vulnerable loop is in the production parser path itself
• the copy bound is derived from the remaining frame length, not from the destination capacity
• the first overwritten fields after data[234] are live semantic fields, not just padding

My current local evidence includes:

• a concrete arithmetic example where the remaining data exceeds 234 bytes
• field-level evidence showing writes beyond the end of the data field
• one recorded write beyond the record->data field boundary in local analysis
• a local reproducer for the manufacturer-specific branch

At a minimum, this appears capable of causing memory corruption, crashes, or corrupted parser state. I am not claiming code execution.

Suggested remediation:

• compute record->data_len as currently done
• reject the frame if record->data_len > sizeof(record->data)
• only proceed with the copy if the destination bound is respected

I can provide the following in follow-up if helpful:

• a minimal reproducer
• local proof notes / output
• exact tested revision details
• a proposed patch or regression test

I did not find a published security policy for this repository. If you would prefer this to be handled privately first, please let me know the appropriate contact channel.

Best regards,

Pengpeng Hou
pengpeng@iscas.ac.cn

[lategoodbye]

I've send you an email on March 11th. Did you received it?