Two ways to trust bytes you did not write: a kernel SMB overread and a Kubernetes namespace bypass

Two disclosures landed this week that look unrelated (one in the Linux kernel's in-kernel SMB server, one in a Kubernetes integration framework), but they share a single failure pattern that we see over and over: the code trusts the structure of input it did not write. A length field is taken at face value. A namespace name is honored without asking whether the caller is allowed to name it. The fix in both cases is the same idea applied in two very different layers: validate the thing the attacker controls before you act on it.

CVE-2026-43490: ksmbd reads past the end of an ACE

CVE-2026-43490 (CVSS 8.8) is in ksmbd, the in-kernel SMB3 server in Linux. When a client sets an extended attribute carrying an NTFS-style security descriptor, the kernel's smb_inherit_dacl() walks the parent directory's discretionary access control list (DACL) to inherit access control entries (ACEs). It verifies that each ACE contains the fixed-size SID header before reading it, but it does not verify that the variable-length SID, whose subauthority count is described by sid.num_subauth, is fully contained within the ACE.

That is the whole bug. A malformed security descriptor xattr can claim a subauthority count that runs the SID past the end of the ACE buffer. The kernel walks that count and reads adjacent kernel memory: an out-of-bounds read in the most privileged address space on the machine. The trigger reaches the kernel from a network-facing SMB share, which is exactly why it grades 8.8: the attacker shapes the bytes, the kernel trusts the length, and the parser walks off the end.

The defensible probe here is a version-and-exposure check, never an exploit. ksmbd is a kernel module; you fingerprint the kernel build and confirm whether SMB is reachable, you do not throw malformed descriptors at production:

# CVE-2026-43490: is an in-kernel SMB server exposed, and on a pre-fix kernel?
# This is posture only: it reads versions, it sends no malformed descriptor.
uname -r                              # kernel build: compare against your distro's fixed release
lsmod | grep -i ksmbd                 # is the in-kernel server even loaded?
ss -tlnp | grep ':445'                # is SMB listening, and on which interface?
# FINDING only if ksmbd is loaded, listening on a reachable interface, AND the
# kernel predates the fix. A patched or non-exposed host is a PASS.

The fix is to upgrade to the patched kernel, where smb_inherit_dacl() validates that the full SID (header plus num_subauth × 4 bytes) fits inside the ACE before dereferencing it. Operationally: do not expose ksmbd to untrusted networks, and prefer userspace Samba where the threat model warrants the isolation. The deeper lesson is the one every parser author already knows and every parser bug forgets: a length field from the wire is an attacker input, not a fact.

CVE-2026-45760: Camel K builds in a namespace of the attacker's choosing

CVE-2026-45760 (CVSS 8.1) is the authorization-layer cousin. Apache Camel K is a framework for running integration workloads on Kubernetes. The advisory describes two intertwined weaknesses: an externally controlled reference to a resource in another sphere, and an authorization bypass through a user-controlled key. Concretely: a user authorized to create a Build resource in their own Kubernetes namespace can control where the resulting build Pod is generated, including in a namespace of their choosing, up to and including the operator's own namespace.

The user-controlled key is the namespace name. The framework honors it without confirming that the requester is entitled to schedule a Pod there. A tenant who is supposed to be confined to team-a can cause a build Pod to materialize in the operator namespace, where service accounts and secrets are more powerful: a textbook tenancy-boundary break in a multi-tenant cluster. The affected ranges are Camel K 2.0.0 before 2.8.1 and 2.9.0 before the corresponding fixed release.

The safe check is an RBAC and version audit (what can a tenant actually create, and is the operator on a fixed build):

# CVE-2026-45760: can a confined tenant influence Build placement, and is Camel K fixed?
# Posture only: enumerate RBAC + operator version, create nothing cross-namespace.
kubectl get deploy -n camel-k-operator -o jsonpath='{.items[*].spec.template.spec.containers[*].image}'
# Compare the operator image tag against fixed 2.8.1+ / patched 2.9.x.
kubectl auth can-i create builds.camel.apache.org --as=system:serviceaccount:team-a:default -n team-a
# Then confirm the operator's admission/validation rejects a Build whose target
# namespace differs from the requester's. FINDING = a confined SA can place a
# build outside its namespace on a pre-fix operator. A fixed, namespace-pinned
# operator is a PASS.

The fix is to upgrade Camel K to 2.8.1 or the patched 2.9.x train, where the operator binds build placement to the requester's namespace and rejects an attacker-supplied target. Layer defense-in-depth on top: tight RBAC so tenants cannot create privileged resources, and admission policy (e.g. a validating webhook or policy engine) that enforces namespace alignment regardless of what the framework does.

One pattern, two layers

It is worth naming the through-line because it tells you where to look next. In ksmbd, the trusted-but-attacker-controlled value is a length; the consequence is a memory overread. In Camel K, the trusted-but-attacker-controlled value is a name; the consequence is a tenancy escape. The code in both cases performed some validation (ksmbd checked the fixed SID header, Camel K authenticated the user) and then trusted a second field that the same attacker also controlled. Partial validation is the trap. The boundary is only as strong as its weakest unchecked field.

For defenders the takeaway is concrete: patch both on their fixed trains, and treat “authenticated” and “well-formed” as starting points, not conclusions. An authenticated tenant is still an adversary with respect to other tenants. A well-formed header is no promise about the variable-length payload behind it.

How Celvex Sentry tests for this

Our continuous-monitoring suite fingerprints exposed SMB services and kernel builds for the ksmbd class (reachability plus a vulnerable build, never a malformed-descriptor payload against production) and audits Kubernetes RBAC and operator versions for the cross-namespace placement class. When a confined identity can provably act outside its boundary, or an exposed service runs a pre-fix build on a reachable interface, we mint a Proof Capsule with the evidence and the fixed-version remediation attached. When the boundary holds, we record a PASS and move on.