Bug 2462126 (CVE-2026-73583) - CVE-2026-73583 sblim-sfcb: Unsafe deserialization in sblim-sfcb provider-manager IPC allows out-of-bounds memory access via malformed OperationHdr
Summary: CVE-2026-73583 sblim-sfcb: Unsafe deserialization in sblim-sfcb provider-mana...
Keywords:
Status: NEW
Alias: CVE-2026-73583
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On: 2515251
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-04-26 18:19 UTC by OSIDB Bzimport
Modified: 2026-08-13 11:54 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-04-26 18:19:15 UTC
AI_ONLY_REPORT
package: sblim-sfcb-1.4.9-36.el10
------
Summary: Unsafe deserialization of provider-manager IPC message allows  
pointer/length manipulation (OOB read/write): malformed local IPC input can  
drive unchecked `OperationHdr` offset fixups and handler-table indexing in  
the provider-manager, leading to out-of-bounds access and process  
termination.
Requirements to exploit: A local attacker needs access to a system running  
the package and a deployment where the local connect socket is reachable  
closely enough to obtain the internal provider-manager descriptor via  
`MSG_X_LOCAL`. No user interaction is required. Exposure depends on local  
IPC configuration and socket permissions.
Component affected: `sblim-sfcb-1.4.9-36.el10`, provider-manager IPC  
request parsing in `providerMgr.c` (`processProviderMgrRequests()`), with  
the documented access path through `localConnectServer()` in `msgqueue.c`
Version affected: `sblim-sfcb-1.4.9-36.el10`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H - 7.1 (HIGH)
AV:L - Exploitation is through a local IPC channel rather than over the  
network.
AC:L - Once the attacker can use the local connect path, crafting  
malformed `OperationHdr` fields is straightforward.
PR:L - The attacker needs local access sufficient to reach the local  
connect socket and obtain the internal descriptor.
UI:N - No user interaction is required.
S:U - The impact is within the vulnerable service’s security scope.
C:L - Limited unintended disclosure is plausible if invalid offsets are  
dereferenced into mapped memory and consumed by logging or downstream code,  
but broad disclosure is not established.
I:L - Invalid handler selection and malformed in-buffer pointers can  
perturb control flow or request processing, but arbitrary write or  
privilege escalation is not demonstrated from the available evidence.
A:H - A reliable crash of the provider-manager process is directly  
supported by the unchecked dereference and handler lookup.
Impact: Moderate. Based on the Red Hat severity guidance, the available  
evidence supports a locally reachable denial of service and unsafe memory  
access in the provider-manager parser, but not an easy or established route  
to full system compromise. Reachability also depends on local IPC exposure  
and socket permissions, which makes this less severe than a typical  
Important or Critical issue.
Embargo: no
Reason: The issue is local and configuration-dependent, and the  
demonstrated impact is primarily local service disruption rather than easy  
remote compromise.
Acknowledgement: Aisle Research
Vulnerability Details: The directly reachable issue is in  
`processProviderMgrRequests()`. Fields from an IPC-supplied `OperationHdr`  
are trusted before validating that embedded offsets stay within the `rl`  
bytes returned by `spRecvReq()`, and `req->type` is used as a handler-table  
index without a bounds check.
```c
spRecvReq(&sfcbSockets.receive, &requestor, (void **) &req, &rl, &mqg);
req->nameSpace.data = (void *)((long)req->nameSpace.data + (char *)req);
if (req->className.length)
req->className.data = (void *)((long)req->className.data + (char *)req);
_SFCB_TRACE(1, ("--- Mgr request for %s-%s (%d) from %d",
req->nameSpace.data, req->className.data, req->type,  
requestor));
hdlr = mHandlers[req->type];
hdlr.handler(&requestor, req);
```
A malformed message can therefore cause an out-of-bounds string dereference  
in the trace path or an invalid access to `mHandlers[req->type]`, resulting  
in a crash and potentially other unsafe memory effects if the computed  
addresses remain mapped.
The documented local access path is the local connect server, which hands  
out the internal send descriptor on a non-zero request:
```c
if (msg.size != 0) {
spSendCtlResult(&nsocket, &sfcbSockets.send, MSG_X_LOCAL, 0, 0, 0);
}
```
In the reviewed code path, no peer-credential validation is evident before  
that handoff. Exposure therefore depends on who can connect to the local  
socket in a given deployment.
The separately noted arithmetic and copy pattern in `getProviderContext()`  
is worth hardening, but based on the available evidence it is better  
treated as defense-in-depth unless a distinct attacker-controlled path into  
`ctx->oHdr` is demonstrated.
Steps to reproduce:
1. Build the package with `-fsanitize=address,undefined` for deterministic  
diagnostics.
2. Start `sfcbd` with the local connect socket enabled. The reviewed  
materials identify `/tmp/sfcbLocalSocket` as the default `localSocketPath`.
3. Connect to the local connect socket and send a non-zero local-connect  
request to receive the internal descriptor through the `MSG_X_LOCAL` path.
4. Use the received descriptor to send a crafted `MSG_DATA` request  
containing an `OperationHdr` with either an out-of-range `nameSpace.data`  
offset or a `type` value larger than the `mHandlers[]` table.
5. Observe a crash or sanitizer finding during the `%s` trace dereference  
and/or the `mHandlers[req->type]` access in `processProviderMgrRequests()`.
Mitigation: Restrict access to the local connect socket so untrusted local  
users cannot obtain the internal provider-manager descriptor. Deployments  
where only trusted users can reach that socket have materially reduced  
exposure until a fix is available.
Proposed Fix: Validate the received message length, segment offsets and  
lengths, and the handler index before performing any pointer fixup or  
dispatch. A minimal patch for the directly reachable parser issue is:
```diff
diff --git a/providerMgr.c b/providerMgr.c
@@
+static int seg_in_msg(unsigned long rl, MsgSegment s) {
+  uintptr_t off = (uintptr_t)s.data;
+  size_t len = (size_t)s.length;
+  if (off > rl) return 0;
+  if (len > (size_t)(rl - off)) return 0;
+  return 1;
+}
@@ void processProviderMgrRequests()
     if (mqg.rdone) {
+      if (mqg.rdone) {
+        if (rl < sizeof(OperationHdr) ||
+            !seg_in_msg(rl, req->nameSpace) ||
+            (req->className.length && !seg_in_msg(rl, req->className)) ||
+            req->type >= (sizeof(mHandlers) / sizeof(mHandlers[0])) ||
+            mHandlers[req->type].handler == NULL) {
+          free(req);
+          if ((options & OH_Internal) == 0) close(requestor);
+          continue;
+        }
          req->nameSpace.data =
              (void *) ((long) req->nameSpace.data + (char *) req);
          if (req->className.length)
            req->className.data =
                (void *) ((long) req->className.data + (char *) req);
```


Additional hardening: use overflow-safe arithmetic and null checks in  
`getProviderContext()`.
------
This report was generated using AI technology. Always review AI-generated  
content prior to use


Note You need to log in before you can comment on or make changes to this bug.