MLIL call-parameter recovery failure

[mstmhsmt]

Version and Platform (required):

• Binary Ninja Version: 5.4.10257-dev, caa625a3
• OS: macos
• OS Version: 26.5.2
• CPU Architecture: arm64

Bug Description:

MLIL call-parameter recovery drops a stack argument when two adjacent 32-bit outgoing argument slots overlap a previously inferred 64-bit stack variable.

This occurs in the list function of the CGC challenge binary KPRCA_00024/cb_1. A call to sprintf has seven arguments, all of which are clearly present in LLIL:

[esp + 0x00] = edi             // dst
[esp + 0x04] = 0x804bca3      // format
[esp + 0x08] = edi             // prefix
[esp + 0x0c] = esi             // name
[esp + 0x10] = edx             // price_integer
[esp + 0x14] = eax             // price_fraction
[esp + 0x18] = ebx             // count
call(0x804b520)                // sprintf

However, MLIL contains only six parameters:

0x804b520(
    var_105c_1,
    "%s%s (Price: %d.%02d, Count: %d)\n",
    var_1050_1,
    var_104c_1,
    var_1048_1,
    var_1044_1
)

The missing argument is the value stored at [esp + 0x08], which should be the first variadic argument corresponding to the first %s.

LLIL identifies the two adjacent slots as fields of the same eight-byte stack variable:

[esp + 8 {var_1058+0x4}].d = edi
[esp + 4 {var_1058}].d = 0x804bca3

The lower four-byte field at [esp + 4] is recovered as the format argument, but the upper four-byte field at [esp + 8] is not emitted as an independent MLIL call parameter.

A call-site type override does not resolve the issue. The following non-variadic seven-parameter type is correctly applied:

int32_t(
    char* dst,
    const char* format,
    char* prefix,
    char* name,
    int32_t price_integer,
    int32_t price_fraction,
    int32_t count
)

The adjusted type reports seven parameters, cdecl, and has_variable_arguments == false, but both non-SSA MLIL and SSA MLIL still contain only six call parameters.

Because the missing parameter occurs in the middle of the argument list, the displayed parameter names become shifted. This makes the issue appear in the GUI as though the final count parameter were missing, although the value corresponding to count is present as var_1044_1.

Steps To Reproduce:

1. Open the CGC challenge binary KPRCA_00024/cb_1 in Binary Ninja.

2. Navigate to the function list at address 0x08049040.

3. Locate the call instruction at address 0x080490d9, whose destination is sprintf at 0x0804b520.

4. Inspect the LLIL immediately before the call. The relevant instructions are:

0x080490ba [esp + 0x18 {var_1044_1}].d = ebx
0x080490be [esp + 0x0c {var_1050_1}].d = esi
0x080490c2 [esp + 0x08 {var_1058+0x4}].d = edi
0x080490c6 [esp + 0x00 {var_105c_1}].d = edi
0x080490c9 [esp + 0x10 {var_104c_1}].d = edx
0x080490cd [esp + 0x14 {var_1048_1}].d = eax
0x080490d1 [esp + 0x04 {var_1058}].d = 0x804bca3
0x080490d9 call(0x804b520)

5. Inspect the corresponding non-SSA MLIL call. It contains six parameters:

0x804b520(
    var_105c_1,
    "%s%s (Price: %d.%02d, Count: %d)\n",
    var_1050_1,
    var_104c_1,
    var_1048_1,
    var_1044_1
)

6. Inspect the corresponding SSA MLIL call. It also contains six parameters:

mem#4 = 0x804b520(
    var_105c_1#3,
    "%s%s (Price: %d.%02d, Count: %d)\n",
    var_1050_1#2,
    var_104c_1#2,
    var_1048_1#2,
    var_1044_1#2
) @ mem#3

7. Apply the following call-site type override at 0x080490d9:

int32_t(
    char* dst,
    const char* format,
    char* prefix,
    char* name,
    int32_t price_integer,
    int32_t price_fraction,
    int32_t count
)

8. Reanalyze the function and inspect the MLIL again.

9. Observe that the call type has seven non-variadic cdecl parameters, but both MLIL forms still contain only six parameter expressions. The store at [esp + 0x08] remains absent from the call parameters.

Expected Behavior:

MLIL call-parameter recovery should treat each ABI argument slot independently, even when adjacent slots have been grouped into a larger stack variable for another use.

For this call, MLIL should recover all seven arguments:

0x804b520(
    var_105c_1,
    "%s%s (Price: %d.%02d, Count: %d)\n",
    &var_1010,
    var_1050_1,
    var_104c_1,
    var_1048_1,
    var_1044_1
)

Equivalently, the argument stored at [esp + 0x08 {var_1058+0x4}] should be emitted as an independent parameter between the format string and var_1050_1.

Applying a seven-parameter call-site type override should also cause the outgoing stack slots to be reconsidered so that all seven parameter expressions are generated.