[renovate]

This PR contains the following updates:

Package	Type	Update	Change	Age	Confidence
tokio (source)	workspace.dependencies	patch	1.53.2 → 1.53.3
zod (source)	dependencies	patch	4.6.5 → 4.6.6

---

AsyncFd::new and related constructors violate I/O safety

RUSTSEC-2026-0386

More information

Details

tokio::io::unix::AsyncFd provides safe constructors (new, with_interest, try_new, and try_with_interest) that accept any T: AsRawFd rather than requiring proof of ownership or validity of the file descriptor. Because RawFd implements AsRawFd, safe code can construct an AsyncFd from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the AsyncFd is still alive.

This violates I/O safety in two ways:

1. AsyncFd<T> implements AsFd for all T: AsRawFd by calling BorrowedFd::borrow_raw(self.as_raw_fd()), allowing safe code to obtain an arbitrary BorrowedFd<'_> without owning the file descriptor.
2. Tokio's I/O driver stores a pointer to an internal allocation in the epoll/kqueue user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an AsyncFd is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the first AsyncFd deregisters the reused file descriptor number and frees the first while the original file description remains registered in epoll, leading to a use-after-free when a readiness event fires.

Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, AsyncFd::new, AsyncFd::with_interest, AsyncFd::try_new, and AsyncFd::try_with_interest are deprecated in favor of the unsafe constructors AsyncFd::register and AsyncFd::register_with_interest. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the AsyncFd.

Severity

Unknown

References

• https://crates.io/crates/tokio
• https://rustsec.org/advisories/RUSTSEC-2026-0386.html
• https://github.com/tokio-rs/tokio/pull/8587
• https://github.com/tokio-rs/tokio/issues/8538
• https://github.com/tokio-rs/tokio/issues/8539

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

---

Zod can exhaust memory while validating oversized constrained collections

CVE-2023-54404 / GHSA-mrhx-c7xc-m3w5

More information

Details

Zod schema-validation library through 4.6.5 contains an uncontrolled resource consumption vulnerability that allows attackers to exhaust memory by submitting a large array to an application using an array schema without a length constraint. Attackers can exploit the handleArrayResult parse logic in $ZodArray, which accumulates every validation issue for each failing element with no cap or early termination, causing the process to allocate excessive issue objects and crash due to out-of-memory conditions.

Severity

• CVSS Score: 8.2 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

• https://nvd.nist.gov/vuln/detail/CVE-2023-54404
• https://github.com/colinhacks/zod/issues/1872
• https://github.com/colinhacks/zod/pull/6475
• https://github.com/colinhacks/zod/pull/6652
• https://github.com/colinhacks/zod/commit/a0ebf970f2d752e5f58527cd2942ff48be4f46bd
• https://github.com/colinhacks/zod
• https://www.vulncheck.com/advisories/zod-uncontrolled-resource-consumption-via-array-validation

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

tokio-rs/tokio (tokio)

v1.53.3: Tokio v1.53.3

Compare Source

1.53.3 (October 13th, 2026)

Added

• io: add AsyncFd::register and AsyncFd::register_with_interest (#​8587)

Changed

• io: deprecate AsyncFd::{new, with_interest, try_new, try_with_interest} (#​8587)

Fixed

• io: wake and drop DuplexStream wakers outside the lock (#​8618)
• macros: avoid unreachable_code in join! and try_join! for Infallible (#​8518)
• runtime: fix paused time auto-advancing when I/O wakes a task on current_thread (#​8595)
• sync: wake waiters outside the lock when closing a semaphore (#​8529)
• test: fix several flaky tests (#​8196, #​8427, #​8609)

Fixed (unstable)

• rt: keep io_uring op alive when submission fails after push (#​8185)

colinhacks/zod (zod)

v4.6.6

Compare Source

Six malicious commits pushed to main on September 21 with a compromised git credential were reverted the same day in #​6620 and have since been removed from the history of main. None were ever published to npm. The npm provenance for 4.6.6 names 284243f, the pre-rewrite copy of 9c21983 with identical contents.

Commits:

• 0cd3af5 docs: load the en locale directly in Zod Mini
• 9d5e60f docs: import locales from zod/locales, not z.locales
• 34a626f docs: tighten the z.locales tree-shaking note
• 74304ce release: stage npm versions instead of publishing them (#​6622)
• b2ef983 docs: add Code for Japan to bronze sponsors
• 8fb2faf docs: crop the Code for Japan logo and list it first in bronze
• bacad51 docs: square the Code for Japan logo to match the other bronze tiles
• c42596b release: hold the run on the release-approval environment until the staged versions are approved (#​6638)
• a2ba4a6 fix(types): declare record output and input as members, not base type arguments (#​6645)
• a0ebf97 fix(v4): check array, set and map size bounds before parsing elements (#​6652)
• 529f78d 4.6.6
• 9c21983 ci: stage at verbose so a failed OIDC token exchange says why

---

Configuration

📅 Schedule: (in timezone Europe/Warsaw)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.