**Package:** `samba-4.23.5-105.el10` **CVSS:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H` -- 6.5 (MEDIUM) **Impact:** Important **Embargo:** no **Report Type:** AI-Generated --- ## Summary SMB2 CREATE context parsing allows resource-exhaustion via excessive/overlapping blob entries: crafted SMB2 CREATE context buffers can force disproportionate CPU and memory consumption in the create-blob parser. ## Requirements to Exploit The attacker must deliver a crafted SMB2 CREATE context buffer with many small, syntactically valid entries. This is reachable either by operating an SMB server that a victim client connects to, or by authenticating to a Samba server and reaching the CREATE path after session setup and tree connect. The issue is bounded by SMB framing, but that bound is still large enough to create substantial parser work and allocation pressure. ## Component Affected `samba-4.23.5-105.el10`, `libcli/smb/smb2_create_blob.c`, `smb2_create_blob_parse()` and `smb2_create_blob_add()`, reachable from `libcli/smb/smb2cli_create.c` and `source3/smbd/smb2_create.c` ## Version Affected `samba-4.23.5-105.el10` ## Patch Available no released package fix established; proposed patch excerpt included below ## Version Fixed unknown ## Upstream Coordination This report serves as the initial notification. ## CVSS `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H` -- 6.5 (MEDIUM) ### Metric Justification - **AV (Attack Vector):** N - The vulnerable parser is reached through SMB2 network traffic. - **AC (Attack Complexity):** L - Crafting many syntactically valid create-context entries is straightforward once the message layout is known. - **PR (Privileges Required):** N - The chosen vector models the client-side malicious-server path, which does not require prior privileges on the victim system. - **UI (User Interaction):** R - A victim must connect to the attacker-controlled SMB server for the PR:N path; the server-side path also exists but requires an authenticated SMB2 session. - **S (Scope):** U - The impact remains within the security scope of the affected Samba component processing the CREATE contexts. - **C (Confidentiality):** N - No confidentiality impact is established. - **I (Integrity):** N - No integrity impact is established. - **A (Availability):** H - A single crafted request or response can cause disproportionate CPU and memory consumption and materially degrade availability. ## Impact Assessment Important. Red Hat classifies remote denial of service issues that can readily compromise availability as Important. The established impact here is limited to availability, so this is not Critical, but the parser is network reachable in standard SMB2 CREATE processing and can be driven into substantial CPU and heap consumption within a bounded request or response. The need for either user interaction on the client side or authenticated access on the server side constrains exploitability, but not enough to reduce the issue to Moderate. ## Embargo no ## Embargo Rationale The available evidence supports an availability-only issue with constrained reachability rather than system compromise, and short-term operational mitigations exist while a fix is prepared. ## Acknowledgement Aisle Research ## Vulnerability Details The parser walks attacker-controlled create-context records, validates them only against the remaining buffer, allocates per record, and appends each parsed blob via per-entry reallocation. ```c while (remaining > 0) { ... next = IVAL(data, 0); name_offset = SVAL(data, 4); name_length = SVAL(data, 6); ... data_offset = SVAL(data, 10); data_length = IVAL(data, 12); if ((next & 0x7) != 0 || next > remaining || name_offset != 16 || name_length < 4 || name_offset + name_length > remaining || (data_offset & 0x7) != 0 || (data_offset && (data_offset < name_offset + name_length)) || (data_offset > remaining) || (data_offset + (uint64_t)data_length > remaining)) { return NT_STATUS_INVALID_PARAMETER; } tag = talloc_strndup(mem_ctx, (const char *)data + name_offset, name_length); ... status = smb2_create_blob_add(mem_ctx, blobs, tag, b); ... if (next == 0) break; remaining -= next; data += next; ... } ``` ```c array = talloc_realloc(mem_ctx, b->blobs, struct smb2_create_blob, b->num_blobs + 1); ``` Observed: there is no explicit limit on blob count or aggregate parsed or allocated bytes, and the per-record extent checks are performed against `remaining`, not against the current record length `next`. Reasonable inference: a crafted bounded buffer can keep `next` small while still referencing later bytes within the still-remaining region, maximizing iteration count and forcing repeated reallocations plus tag and data duplication. Uncertainty: the available evidence supports denial of service and degraded availability only. It does not establish code execution, confidentiality impact, integrity impact, or a precise exhaustion threshold. ## Steps to Reproduce 1. Build the package with symbols and monitor CPU time and heap usage. 2. For the client-side path, perform an operation that issues SMB2 CREATE and have a malicious SMB server return a CREATE response whose context buffer contains many small valid entries. 3. For the server-side path, establish an authenticated SMB2 session and tree connect, then send CREATE requests with a large context buffer composed of many small valid entries. 4. Keep `next` 8-byte aligned and small, while ensuring the name and data offsets and lengths still satisfy the parser's `remaining`-based checks. 5. Observe high time in `smb2_create_blob_parse()` and `smb2_create_blob_add()`, repeated realloc or copy growth of the blob array, and substantial per-request heap growth. 6. Compare against a control run with a normal small context count to confirm the disproportionate delta. ## Mitigation Until a code fix is available, avoid connecting affected SMB clients to untrusted SMB servers, and restrict server-side SMB access to trusted users and networks. Resource limits and monitoring may reduce impact, but they do not remove the parser-side amplification. ## Proposed Fix Add explicit limits on per-message blob count and aggregate parsed bytes, and reject records whose name or data extents exceed the current `next` stride. A minimal diff excerpt is below. ```diff diff --git a/libcli/smb/smb2_create_blob.c b/libcli/smb/smb2_create_blob.c index XXXXXXX..YYYYYYY 100644 — a/libcli/smb/smb2_create_blob.c +++ b/libcli/smb/smb2_create_blob.c @@ -23,6 +23,10 @@ #include "includes.h" #include "../libcli/smb/smb_common.h" +#define SMB2_CREATE_BLOB_MAX_COUNT 8192 +#define SMB2_CREATE_BLOB_MAX_TOTAL_BYTES (4 * 1024 * 1024) +#define SMB2_CREATE_BLOB_MIN_REC_SIZE 16 + static size_t smb2_create_blob_padding(uint32_t offset, size_t n) { if ((offset & (n-1)) == 0) return 0; @@ -36,6 +40,8 @@ NTSTATUS smb2_create_blob_parse(TALLOC_CTX *mem_ctx, const DATA_BLOB buffer, { const uint8_t *data = buffer.data; uint32_t remaining = buffer.length; + uint32_t blob_count = 0; + size_t total_bytes = 0; while (remaining > 0) { uint32_t next; @@ -62,6 +68,10 @@ NTSTATUS smb2_create_blob_parse(TALLOC_CTX *mem_ctx, const DATA_BLOB buffer, if ((next & 0x7) != 0 || next > remaining || name_offset != 16 || + (next != 0 && next < SMB2_CREATE_BLOB_MIN_REC_SIZE) || + (next != 0 && (name_offset + name_length > next)) || + (next != 0 && data_offset > next) || + (next != 0 && (data_offset + (uint64_t)data_length > next)) || name_length < 4 || name_offset + name_length > remaining || (data_offset & 0x7) != 0 || @@ -70,6 +80,18 @@ NTSTATUS smb2_create_blob_parse(TALLOC_CTX *mem_ctx, const DATA_BLOB buffer, (data_offset + (uint64_t)data_length > remaining)) { return NT_STATUS_INVALID_PARAMETER; } + blob_count+; + if (blob_count > SMB2_CREATE_BLOB_MAX_COUNT) { + return NT_STATUS_INVALID_NETWORK_RESPONSE; + } + + total_bytes += sizeof(struct smb2_create_blob); + total_bytes += name_length; + total_bytes += data_length; + if (total_bytes > SMB2_CREATE_BLOB_MAX_TOTAL_BYTES) { + return NT_STATUS_INVALID_NETWORK_RESPONSE; + } tag = talloc_strndup(mem_ctx, (const char *)data + name_offset, name_length); if (tag == NULL) { ``` --- *This report was generated using AI technology. Always review AI-generated content prior to use.* Reported by Red Hat Poduct Security.
Created attachment 19230 [details] Patch I'd propose a different approach: First validate without allocating, then allocate the whole thing with talloc_pooled_object.
Shouldn't we open this bug? This is probably not the first and not the last resource consumption DoS we have....
I'm fine if we do not treat this as a security bug.