Revert "deps(rust): bump time to 0.3.47 to fix CVE-2026-25727"

[up2wing]

Summary

The time 0.3.47 portion of #267 broke hypervisor-integration CI.
Revert that single bump while keeping the other security fixes from
#267 (vmm-sys-util, bytes, env_logger).

Why

time 0.3.47 pins time-core =0.1.8, which is the first time-core
release that uses edition = "2024". edition2024 requires Rust

= 1.85.0, but:

• hypervisor/Cargo.toml declares rust-version = "1.77.0"
• hypervisor-integration.yaml runs dev_cli.sh tests against
  ghcr.io/cloud-hypervisor/cloud-hypervisor:20240507-0, which ships
  cargo 1.77.0

So CI fails at the manifest-parsing stage:

error: failed to parse manifest at .../time-core-0.1.8/Cargo.toml feature edition2024 is required

Why It's Safe to Revert the Time Bump

CVE-2026-25727 is a stack-exhaustion DoS that requires parsing
user-controlled input with the RFC 2822 format. This codebase
only uses time::format_description::well_known::Rfc3339 (in
CubeShim/shim/src/log/mod.rs) for outbound timestamp formatting,
and never invokes Rfc2822 parsing on untrusted input. The vulnerable
attack vector is not reachable here.

Why Not Just Bump CI / MSRV

Raising the MSRV would conflict with downstream constraints: cube-shim
uses rust-toolchain.toml = "1.77.2" and links the hypervisor crate
through a path dependency, so the hypervisor library must remain
buildable on the same toolchain.

Verification

• cargo metadata --locked succeeds in hypervisor/ under
  cloud-hypervisor:20240507-0 (cargo 1.77.0).
• make shim succeeds end-to-end.
• Diff is minimal: 3 files (agent/Cargo.toml, agent/Cargo.lock,
  hypervisor/Cargo.lock), restoring exactly the pre-CVE fix #267 state of
  the time family.

[kinwin-ustc]

/cubebot review

[github-actions]

Claude finished @kinwin-ustc's task in 1m 25s —— View job

---

Review of PR #286: Revert "deps(rust): bump time to 0.3.47 to fix CVE-2026-25727"

Summary

This PR selectively reverts the time crate bump from #267 (0.3.47 → 0.3.41 in agent, 0.3.47 → 0.3.36 in hypervisor's transitive dep) while preserving all other security fixes from that PR (vmm-sys-util, bytes, env_logger). 3 files changed. 1 commit.

Root Cause Verified

time 0.3.47 → time-core 0.1.8 → edition = "2024" → requires Rust ≥ 1.85.0. The CI environment (cloud-hypervisor:20240507-0, cargo 1.77.0) and the project's rust-toolchain.toml = "1.77.2" cannot parse the manifest. The failure is a hard blocker at the dependency-resolution stage.

Severity: 🟢 Correctly identified and cleanly scoped.

CVE Risk Assessment

Aspect	Finding
CVE	CVE-2026-25727 — stack-exhaustion DoS via Rfc2822 parsing
Codebase usage of time	Rfc3339 for outbound timestamp formatting only (CubeShim/shim/src/log/mod.rs:18,321,407)
Rfc2822 usage	None found anywhere in the codebase
CVE reachable?	No — the vulnerable codepath is never invoked
Risk of revert	Low — the attack vector is not present

Changes Review

1. agent/Cargo.toml — Correct

-time = "0.3.47"
+time = "0.3.41"

Restores the exact version present before #267 (confirmed against parent commit 6d6b3c57). No other dependencies touched. ✅

2. agent/Cargo.lock — Clean

Only the time family of packages (time, time-core, time-macros, num-conv) and their transitive serde dependency are reverted. No orphaned entries or resolution conflicts. ✅

3. hypervisor/Cargo.lock — Clean but note the wider diff

The hypervisor lockfile shows additional reverts (serde 1.0.228→1.0.209, serde_derive, syn 2.0.87→2.0.77, deranged 0.5.8→0.3.11) that are passive lockfile resolution changes, not manifest changes. These occur because:

• time 0.3.47 introduced serde_core as a crate-level re-export, pulling in newer serde/syn versions
• With time reverted to 0.3.36, the resolver falls back to the older crate versions that were already in the tree

These are inert — no code changes, no API changes in the final binary. ✅

Suggestions

None. This is a clean, minimal, well-scoped revert. The PR description accurately documents:

• The root cause (edition2024 + MSRV mismatch)
• Why a re-revert is acceptable (CVE not reachable)
• Why not to bump MSRV instead (downstream rust-toolchain.toml = "1.77.2" constraint)
• What was verified (cargo metadata --locked, make shim)

Questions

• Are there plans to upgrade the CI Docker image (cloud-hypervisor:20240507-0) to a newer Rust version in a follow-up? Re-landing the time bump would be possible once CI ships Rust ≥ 1.85.0.
• Could time be isolated behind a feature flag on the hypervisor crate to allow the agent crate (which already uses time in its manifest) to consume 0.3.47 independently?

---