STATUS_BUFFER_OVERFLOW on ListShares should only be warning, not error

[elchtest]

It appears that when using SMB to macOS, there was a case when the smb2client gave STATUS_BUFFER_OVERFLOW on ListShares. Then it will abort as error. According to MS docu https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-ntstatus-values, it should only be a warning and it might still return relevant data. Sadly, I only saw the issue in a log file, so I cannot replicate it right now, but still wanted to report it in.

SMBLibrary: 1.5.0
Used from: Android 14

I played a bit around with AI on this topic to try to use at least the first batch of data, if there is any. It does not request more data as it probably should in a clean implementation. Feel free to ignore it if it doesn't make sense:

• In SMBLibrary Client helper (ServerServiceHelper.ListShares), the code treated non-STATUS_SUCCESS as immediate failure after named pipe RPC calls.
• For SMB2, DeviceIOControl on FSCTL_PIPE_TRANSCEIVE can return STATUS_BUFFER_OVERFLOW and still provide output bytes.
• Because ListShares rejected that status early, share enumeration data could be discarded before parsing.

Code Change Implemented
File changed:

• SMBLibrary/Client/Helpers/ServerServiceHelper.cs

What changed:

• Replaced strict checks:
  • from: status == STATUS_SUCCESS only
  • to: allow STATUS_SUCCESS or STATUS_BUFFER_OVERFLOW when output payload exists
• Added helper method:
  • IsUsableRpcPipePayloadStatus(NTStatus status, byte[] output)
  • returns true only when output is non-null/non-empty and status is SUCCESS or BUFFER_OVERFLOW
• Applied to:
  • initial DeviceIOControl(FSCTL_PIPE_TRANSCEIVE) response handling
  • continuation ReadFile response handling in fragment loop

Scope intentionally limited:

• No pagination/resume-handle work added yet
• No broad result-code remapping added yet
• No cleanup refactor (pipe handle leak paths) in this pass

Suggested Next Steps (Future)
Implement proper NetrShareEnum continuation support:

• Handle RPC result ERROR_MORE_DATA
• Send follow-up requests with resume handle until completion or limit
• Merge all returned entries robustly

Improve RPC/SRVSVC result mapping:

• Add explicit handling for more Win32 results (including ERROR_MORE_DATA)
• Preserve partial results where meaningful

Fix resource cleanup paths:

• Ensure pipe handle close in finally block to avoid leak on early returns

Patch (no pagination):
listshares-buffer-overflow-fix.patch

Many thanks for looking at it and your great library!

[TalAloni]

Thanks,
The issue with STATUS_BUFFER_OVERFLOW is that you end-up with a non-complete response, adding the necessary logic to parse it correctly is not the solution because returning 3 shares when the client expects 5 is not a solution.

Usually when the server return STATUS_BUFFER_OVERFLOW it is to indicate that the result is larger than the maximum allowed by the client, and in that case the client should reissue the request with a larger maximum.
Does the server you've seen this on has a long list of shares?
A packet capture or repro instructions would go a long way here.

[elchtest]

Many thanks for your fast reply! Ah, sounds reasonable with resending the request with a larger buffer. I don't have more information yet on how many shares the user had, but reached out and hope to get a reply. Meanwhile, I tried in Windows 11 to do about 30 shares with comments/remarks using 255 characters. ListShares seems to work there.

Some debug output from a small probe built against upstream SMBLibrary (commit 7742c28). I added logging around the same NetrShareEnum path used by ServerServiceHelper.ListShares (TreeConnect IPC$ -> BindPipe -> FSCTL_PIPE_TRANSCEIVE -> continuation ReadFile).

Raw share info via NetrShareEnum level 1 (includes remark lengths):
TreeConnect IPC$ status: STATUS_SUCCESS
BindPipe status: STATUS_SUCCESS, maxTransmitFragmentSize: 4280
FSCTL_PIPE_TRANSCEIVE status: STATUS_SUCCESS, outputBytes: 4280, maxOutputLength: 4280
ReadFile fragment status: STATUS_SUCCESS, outputBytes: 4280
ReadFile fragment status: STATUS_SUCCESS, outputBytes: 4280
ReadFile fragment status: STATUS_SUCCESS, outputBytes: 2024
RPC fragments: 4, responseDataBytes: 14768
NetrShareEnum result: ERROR_SUCCESS, totalEntries: 28, resumeHandle: 0
ShareInfo1 entries parsed: 28

I will try next on macOS to do a larger number of shares with remarks.

[elchtest]

For macOS, I made a script creating folders like SMBTEST_001_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX which uses 80 chars which I believe is the max length on macOS and shared them over script. Remarks/comments seem not to be supported.

It seemed to work:
TreeConnect IPC$ status: STATUS_SUCCESS
BindPipe status: STATUS_SUCCESS, maxTransmitFragmentSize: 5680
FSCTL_PIPE_TRANSCEIVE status: STATUS_BUFFER_OVERFLOW, outputBytes: 5680, maxOutputLength: 5680
ReadFile fragment status: STATUS_SUCCESS, outputBytes: 5680
ReadFile fragment status: STATUS_SUCCESS, outputBytes: 5680
ReadFile fragment status: STATUS_SUCCESS, outputBytes: 3920
RPC fragments: 4, responseDataBytes: 20864
NetrShareEnum result: ERROR_SUCCESS, totalEntries: 107, resumeHandle: 0
ShareInfo1 entries parsed: 107

Sorry, it looks like I am not able to replicate this issue causing the STATUS_BUFFER_OVERFLOW. How would you suggest to proceed?

[TalAloni]

Hi and Thanks,
This issue may be tied to a specific macOS version.
I'm confused though, I'm seeing "FSCTL_PIPE_TRANSCEIVE status: STATUS_BUFFER_OVERFLOW" is that from the repro? you mentioned that the original issue happened with 1.5.0 - are you trying to repro with the latest?

[elchtest]

Oh, I am very sorry. I have read the output messages for the macOS too quickly seeing "SUCCESS" and missed that it did actually get to STATUS_BUFFER_OVERFLOW! This was against the latest SMBLibrary. So then it is easy to reproduce on the latest macOS versions using the standard macOS SMB file sharing. I just tested it again on the latest current macOS Tahoe 26.5, yesterday I ran it with 26.3 when it also happened.

Do you have a macOS system available where you could run the test yourself?

I simplified the test program a bit:

using System.Net;
using SMBLibrary;
using SMBLibrary.Client;

// Maintainer reproduction sample using official upstream SMBLibrary only.
// Usage: dotnet run --project Tools/ListSharesMaintainerSample/ListSharesMaintainerSample.csproj -- <ip> <username> <password> [domain]

if (args.Length < 3)
{
    Console.WriteLine("Usage: ListSharesMaintainerSample <ip> <username> <password> [domain]");
    return 2;
}

string ipText = args[0];
string username = args[1] ?? string.Empty;
string password = args[2] ?? string.Empty;
string domain = args.Length >= 4 ? args[3] ?? string.Empty : string.Empty;

if (!IPAddress.TryParse(ipText, out IPAddress? ipAddress))
{
    Console.WriteLine($"INPUT ParseIP(ip='{ipText}') -> FAIL");
    return 3;
}

Console.WriteLine("=== ListSharesMaintainerSample ===");
Console.WriteLine($"UTC={DateTime.UtcNow:O}");
Console.WriteLine($"INPUT ip={ipAddress} usernameLen={username.Length} passwordLen={password.Length} domainLen={domain.Length}");

SMB2Client client = new SMB2Client(responseTimeoutInMilliseconds: 10000);
bool connected = false;
bool loggedIn = false;

try
{
    Console.WriteLine($"CALL SMB2Client.Connect(serverAddress={ipAddress}, transport={SMBTransportType.DirectTCPTransport})");
    connected = client.Connect(ipAddress, SMBTransportType.DirectTCPTransport);
    Console.WriteLine($"RET  SMB2Client.Connect -> isConnected={connected}");

    if (!connected)
    {
        Console.WriteLine("END  Connect failed; not attempting Login/ListShares");
        return 10;
    }

    Console.WriteLine($"CALL SMB2Client.Login(domainLen={domain.Length}, userLen={username.Length}, passLen={password.Length})");
    NTStatus loginStatus = client.Login(domain, username, password);
    Console.WriteLine($"RET  SMB2Client.Login -> NTStatus={loginStatus}");

    if (loginStatus != NTStatus.STATUS_SUCCESS)
    {
        Console.WriteLine("END  Login failed; not attempting ListShares");
        return 11;
    }

    loggedIn = true;

    Console.WriteLine("CALL SMB2Client.ListShares(out status)");
    List<string>? shares = client.ListShares(out NTStatus listStatus);
    Console.WriteLine($"RET  SMB2Client.ListShares -> NTStatus={listStatus}, shareCount={(shares == null ? 0 : shares.Count)}");

    if (shares != null)
    {
        for (int i = 0; i < shares.Count; i++)
        {
            Console.WriteLine($"SHARE[{i}] {shares[i]}");
        }
    }

    if (listStatus != NTStatus.STATUS_SUCCESS)
    {
        Console.WriteLine("END  ListShares returned non-success NTStatus");
        return 12;
    }

    Console.WriteLine("END  Success");
    return 0;
}
catch (Exception ex)
{
    Console.WriteLine($"EXC  {ex.GetType().Name}: {ex.Message}");
    Console.WriteLine(ex.ToString());
    return 99;
}
finally
{
    if (connected && loggedIn)
    {
        try
        {
            Console.WriteLine("CALL SMB2Client.Logoff()");
            NTStatus logoffStatus = client.Logoff();
            Console.WriteLine($"RET  SMB2Client.Logoff -> NTStatus={logoffStatus}");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"EXC  Logoff: {ex.GetType().Name}: {ex.Message}");
        }
    }

    try
    {
        Console.WriteLine("CALL SMB2Client.Disconnect()");
        client.Disconnect();
        Console.WriteLine("RET  SMB2Client.Disconnect -> done");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"EXC  Disconnect: {ex.GetType().Name}: {ex.Message}");
    }
}

Part of the output:

RET  SMB2Client.Connect -> isConnected=True
CALL SMB2Client.Login(domainLen=0, userLen=xxx, passLen=xxx) [xxx replaced by me]
RET  SMB2Client.Login -> NTStatus=STATUS_SUCCESS
CALL SMB2Client.ListShares(out status)
RET  SMB2Client.ListShares -> NTStatus=STATUS_BUFFER_OVERFLOW, shareCount=0
END  ListShares returned non-success NTStatus
CALL SMB2Client.Logoff()
RET  SMB2Client.Logoff -> NTStatus=STATUS_SUCCESS

Here is the script I used to create 100 long-named shares on macOS:

cat > ~/create_smb_listshares_test.sh <<'EOF'
#!/bin/bash
set -euo pipefail

BASE="$HOME/Desktop/mac_smb_listshares_test"
COUNT=100

mkdir -p "$BASE"

echo "Creating $COUNT folders and SMB shares under:"
echo "  $BASE"
echo

for i in $(seq 1 "$COUNT"); do
    num=$(printf "%03d" "$i")
    folder=$(printf "%02d" "$i")

    path="$BASE/$folder"
    record="SMBTEST_$num"

    # Prefix is 12 chars: SMBTEST_001_
    # Filler makes total SMB share name exactly 80 ASCII chars.
    prefix="SMBTEST_${num}_"
    filler_len=$((80 - ${#prefix}))
    filler=$(printf "%*s" "$filler_len" "" | tr ' ' 'X')
    smbname="${prefix}${filler}"

    if [ "${#smbname}" -ne 80 ]; then
        echo "Internal error: SMB name length is ${#smbname}, expected 80"
        exit 1
    fi

    mkdir -p "$path"

    # Remove an old test share with the same record name, if present.
    sudo /usr/sbin/sharing -r "$record" >/dev/null 2>&1 || true

    # Add the share.
    # -a  path to share
    # -n  internal share-point record name, useful for cleanup
    # -S  SMB-visible share name
    # -s  001 = enable SMB
    # -g  000 = disable guest access
    # -R  0   = not read-only
    sudo /usr/sbin/sharing -a "$path" \
        -n "$record" \
        -S "$smbname" \
        -s 001 \
        -g 000 \
        -R 0

    echo "Added $record -> $smbname"
done

echo
echo "Done. Current SMBTEST shares:"
/usr/sbin/sharing -l | grep -A5 'SMBTEST_' || true
EOF

chmod +x ~/create_smb_listshares_test.sh
~/create_smb_listshares_test.sh

[TalAloni]

Thank you,
I don't have a mac OS, can you please provide WireShark capture (so I can code the server to simulate how mac OS behaves and then update the client accordingly)?

[TalAloni]

I tested today with mac OS 12.0.1 which I happen to have available.
The issue did not reproduce there.
A WireShark capture would be useful.

[elchtest]

Thanks for testing meanwhile on macOS 12. I will try to run it with WireShark later this week or next week and report back.