Missing Input Validation in MC cpio VFS Handler

[RCydefe]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

4.8.33 (commit f03e97f25, and likely all prior versions)

Operating system

Kali linux 6.19.14

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

1. Create a crafted cpio archive with a symlink entry where c_filesize is set to
   a large value (e.g., 0xFFFFFFFF in new ASCII format or 77777777777 in old ASCII
   format).

2. Victim opens the archive in Midnight Commander — e.g., navigates to the file in
   mc and presses Enter to browse the archive.

3. MC's VFS layer calls cpio_open_archive() → cpio_read_head() →
   cpio_create_entry(), which reaches the vulnerable allocation at line 521.

No further user interaction is required — the crash occurs during initial archive
parsing.

Expected behavior

When mc opens crafted.cpio:

1. cpio_read_head() parses the header and stores filesize = 0xFFFFFFFF into
   st->st_size
2. cpio_create_entry() reaches line 521: g_malloc(0xFFFFFFFF + 1)
3. GLib attempts a 4 GB allocation — on systems without sufficient virtual memory
   or with strict limits, GLib's allocator calls g_error() and aborts
4. mc terminates immediately — before any content is displayed

Actual behavior

mc crashes when opening a crafted cpio archive.
The crash occurs during initial archive parsing before any user interaction.

Additional context

A missing input validation vulnerability exists in the cpio VFS handler's
cpio_create_entry() function. When a malformed cpio archive contains a symlink entry
with a large c_filesize field, the value is passed directly to g_malloc() and
mc_read() without any bounds checking or sanity validation.

On 64-bit Linux, the attacker-controlled filesize value flows into
g_malloc(st->st_size + 1), causing mc to attempt to allocate up to 4–8 GB of
memory. GLib's allocator calls g_error() and aborts when the allocation cannot be
satisfied, crashing mc. The mc_read() call then attempts to read up to 4 GB of
data from the archive file descriptor into the allocation.

No user interaction beyond opening the archive is required. The vulnerability fires
during initial archive parsing before any user action within mc.

[RCydefe]

Apologies for all the reports, I am practicing my bug hunting and I chose your software as my practice use case.

[zyv]

I think that this is a duplicate of #5084 / #5089 - please test the fix in the proposed PR.

[zyv]

Apologies for all the reports, I am practicing my bug hunting and I chose your software as my practice use case.

You don't have to apologize, just realize that as a 30-year-old project written in C, which is maintained as a hobby, only getting a few hours per week of attention at best, mc is most certainly full of formal bugs of different severities.

Only running automated tools to uncover them is marginally helpful unless you are going to put the effort to provide high-quality fixes and refactoring with tests. There is nobody there to triage this stuff and fix it working full-time behind the scenes for the benefit of the project...

[RCydefe]

I think that this is a duplicate of #5084 / #5089 - please test the fix in the proposed PR.

you are correct, it is the same as #5089. Sorry about that.