Bug 16155 - [SECURITY] SMB2 CREATE context parsing allows resource-exhaustion via excessive/overlapping blob entries
Summary: [SECURITY] SMB2 CREATE context parsing allows resource-exhaustion via excessi...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.24.3
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-07-03 09:05 UTC by Andreas Schneider
Modified: 2026-09-18 09:39 UTC (History)
4 users (show)

See Also:


Attachments
Patch (25.21 KB, patch)
2026-09-18 08:42 UTC, Volker Lendecke
vl: review? (asn)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schneider 2026-07-03 09:05:52 UTC
**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.
Comment 1 Volker Lendecke 2026-09-18 08:42:38 UTC
Created attachment 19230 [details]
Patch

I'd propose a different approach: First validate without allocating, then allocate the whole thing with talloc_pooled_object.
Comment 2 Volker Lendecke 2026-09-18 08:43:39 UTC
Shouldn't we open this bug? This is probably not the first and not the last resource consumption DoS we have....
Comment 3 Andreas Schneider 2026-09-18 09:05:08 UTC
I'm fine if we do not treat this as a security bug.
Comment 4 Volker Lendecke 2026-09-18 09:39:21 UTC
Shouldn't we open this bug? This is probably not the first and not the last resource consumption DoS we have....