skb_zerocopy: ZDI-CAN-33367 Risk and Host Checks

ZDI-CAN-33367 is a reported local privilege-escalation issue involving Linux’s skb_zerocopy networking helper. TuxCare reports an in-house root-shell reproduction through a page-cache write and describes a patch under review. Those are TuxCare’s observations, not Penligent test results or a universal distribution fix matrix. TuxCare’s research and response status.

The priority question is which untrusted code can run on the host. A shared hosting account, an untrusted CI job or a shell user may already satisfy the ordinary meaning of “local access.” That is why an internet-facing port check cannot substitute for reviewing the host’s execution boundary. A server can have no public login endpoint and still run code supplied by another tenant or contributor.

Track the report identifier without inventing a CVE

ZDI’s upcoming advisory inventory lists ZDI-CAN-33367 as a Linux report rated 7.8. A CAN identifier is a coordination identifier, not a CVE number. Keep it in the response record so that a team can track vendor updates even when its usual scanner workflow expects a CVE.

This article was reviewed October 24, 2026. It does not assert a current fixed package for any distribution. Recheck upstream and your vendor before making a deployment decision: a posted patch, a merged commit and an installed fix are different milestones. The absence of an assigned scanner finding does not establish the absence of the reported condition.

The boundary is local code versus host-kernel privilege

A local privilege escalation changes what code running under a restricted identity can do. It is distinct from a remote unauthenticated service flaw and from a kernel bug that only causes a crash. TuxCare reports tested distribution cases and discusses user-namespace prerequisites, while acknowledging that proposed mitigations were not validated against its PoC in-house. Research scope and mitigation qualifications.

That qualification should survive in your own ticket. A plausible containment rule can be worth testing without being advertised as a proven fix. Keep the evidence category attached to the statement: researcher reproduction, observed host configuration, proposed restriction, or vendor-delivered correction. Mixing those categories creates false confidence during handoff.

Explore Penligent for authorized security testing

Inventory the running host before considering a change

The proposed checks below read host identity and one namespace limit. Run them only on a system you administer. We did not run them against a customer host. A missing sysctl, restricted container view or permission error is information to investigate, not a value to replace with a presumed default.

uname -r
uname -m
cat /etc/os-release
sysctl user.max_user_namespaces

Record the running kernel, architecture, distribution package revision and workload role together. If you run the commands inside a container, document that context explicitly and obtain the host owner’s evidence as needed. An application team cannot necessarily determine the host’s supported fix state from a container image package list.

For CI, preserve the runner trust policy with the technical inventory. The same kernel may support trusted release jobs and untrusted pull-request jobs; those workloads do not create the same operational risk. Identify who can submit code, how runners are recycled and what state survives between jobs. These are recommended review questions, not claims that a particular pipeline is exploitable.

What user.max_user_namespaces measures

Die kernel documentation for /proc/sys/user describes per-user namespace resource limits. The user.max_user_namespaces setting governs the number of user namespaces that can be created under that accounting. It is a host control to understand, not a standalone vulnerability test.

A proposed restriction on new namespace creation has compatibility consequences. Rootless containers, sandboxed applications and build workflows may depend on the capability. Before changing a production host, test the intended policy on a representative staging workload and obtain the platform owner’s supported procedure. Do not copy a sysctl command into a shared cluster without understanding which workloads it affects.

The distinction between new namespace creation and existing state also matters operationally. A policy rollout needs an explicit plan for already-running workloads and the identities that can change configuration. Record what was changed, what remained running and what the verification actually observed. Avoid describing a single readback as a complete containment result.

A safe model for a remediation queue

We executed the following Python model locally. It uses invented asset records and performs no namespace operation, kernel access or network request. The model separates an untrusted execution boundary from verified fix evidence. It is a planning example, not a detector or an exploit.

def action(untrusted_code, fix_verified, control_verified):
    if fix_verified is True:
        return "Retain fix evidence and regression result"
    if untrusted_code is None:
        return "REVIEW: workload trust boundary unknown"
    if untrusted_code and not control_verified:
        return "Prioritize owner review and containment"
    return "Track vendor fix; retain scoped control evidence"

records = [(True, False, False), (True, False, True),
           (False, True, True), (None, False, False)]
for record in records:
    print(action(*record))

Prioritize owner review and containment
Track vendor fix; retain scoped control evidence
Retain fix evidence and regression result
REVIEW: workload trust boundary unknown

A real implementation needs evidence references for every Boolean field. “Control verified” should name the actual control and scope; “fix verified” should identify the vendor correction and running state. A dashboard becomes misleading when it retains only labels and loses the observations that produced them.

Explore Penligent for authorized security testing

Reduce exposure without claiming the kernel is repaired

Start with the local execution boundary. Limit untrusted code execution on shared sensitive hosts where the workload can be moved or isolated through supported platform controls. For a CI system, that may mean separating untrusted jobs from privileged release workloads; for hosting, it may require vendor coordination rather than a change made by one application tenant.

Any namespace restriction remains a containment measure with a defined scope. Test normal operation, check that the intended restriction is applied through configuration management, and assign an owner for exceptions. A system that cannot adopt a temporary control should remain visible in the queue instead of being marked resolved because a different host was changed.

A patch is not deployed merely because it exists

Ask your kernel vendor for applicability using the report identifier. Retain the advisory, package or livepatch mapping and support statement. Do not install an arbitrary kernel build from a public discussion thread just to make a version number appear newer. A supported backport can be the right correction even when its version string differs from an upstream example.

Once a correction is supplied, verify the active state after the supported update procedure. A package manager can install a kernel while the machine continues running the old one. A livepatch service requires its own applicability and loaded-state evidence. Verify each host in the scoped fleet, including standby runners and templates used to create replacement instances.

Regression checks should use benign workloads: a normal build, expected container startup, required sandbox behavior and application health. They establish that the change supports the workload. They do not reproduce the vulnerability. Kernel exploitation tests belong, if needed at all, in an explicitly authorized disposable lab with specialist review, not a production acceptance script.

Handle suspected compromise separately from patch tracking

If a restricted account appears to have gained unexpected privilege, preserve the host and workload evidence according to the incident plan. Keep timestamps, runner or tenant identity, administrative actions and relevant kernel logs. An update addresses future exposure; it does not establish whether credentials or data were accessed earlier.

Avoid attributing every crash or suspicious command to this report. Correlate observations and retain uncertainty until evidence supports a conclusion. Public research can guide hypotheses, but it cannot substitute for facts from the affected environment.

Frequently asked questions

Is ZDI-CAN-33367 a remotely exploitable SMB flaw?

This article concerns a local privilege-escalation report in skb_zerocopy. KSMBD is a separate report family and must be assessed separately.

Does a namespace setting prove the host is patched?

No. It is a configuration control. A kernel fix requires vendor and active-runtime evidence.

Should every team disable user namespaces immediately?

Evaluate the reported prerequisite and your platform’s supported controls. Test compatibility because legitimate container and sandbox workflows may depend on namespaces.

Why can a scanner miss the report?

Some workflows key findings to CVE identifiers. Track the report identifier and vendor statements rather than equating a missing CVE match with safety.

Did Penligent reproduce root access?

No. Root-shell results are attributed to TuxCare. Our executed code is a synthetic planning model with no kernel interaction.

For an authorized assessment, define the permitted systems and evidence requirements before testing. Evaluate any automation by the observations it can actually preserve. This article does not claim a dedicated Penligent detector or a Penligent reproduction of the reported flaw.

The video below introduces a general AI-assisted pentesting workflow. It is not an exploit demonstration for the issues discussed here.