Look up another CVE · open CVE-2026-93105 in the interactive tracker
CVE-2026-93105
esp: do not unref managed frag pages in esp_ssg_unref()
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem net/ipv4. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-93105 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist. This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites. esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use. Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data().
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/ipv4/esp4.c
net/ipv6/esp6.c
- What this is
- NETWORKING [IPSEC]MAINTAINERS section matched on net/ipv4/esp4* · netdev@vger.kernel.org · Maintained
- Kernel module
- esp4
Check it on the machine
grep -wE 'CONFIG_INET|CONFIG_INET_ESP' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w esp4Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_INET, CONFIG_INET_ESP
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/ipv4
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.11 | 6.18.57 | 1ad6456898f6 |
| 4.11 | 7.2.6 | 26b6b14c7a03 |
| 4.11 | 7.3 | 21697720ff43 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The extra unref is reached from IORING_OP_SEND_ZC/SENDMSG_ZC with IORING_RECVSEND_FIXED_BUF: io_sendmsg_zc() -> sock_sendmsg() -> tcp_sendmsg_locked() -> xfrm_output() -> esp_output_tail() -> esp_ssg_unref(). io_sg_from_iter() is the only site that sets SKBFL_MANAGED_FRAG_REFS; esp_input() never calls esp_ssg_unref(), so a remote ESP packet cannot supply the buggy skb.
- AC:LAttack complexity, low
- tcp_stream_alloc_skb() allocates MAX_TCP_HEADER then skb_reserve()s all of it, so a SEND_ZC TCP skb has ~0 tailroom. esp_output_head() therefore takes inplace=false (tailen > tailroom, nr_frags < MAX_SKB_FRAGS, data_len+tailen <= PAGE_SIZE), after which esp_output_tail() replaces the frags and esp_ssg_unref() always drops the managed pages. The attacker chooses the send size.
- PR:LPrivileges required, low
- io_uring_setup() allows IORING_OP_SEND_ZC when sysctl_io_uring_disabled==0 (default); no capability is checked on that send path. An ESP SA is also required: the attacker can add one in a user+net namespace because xfrm_user_rcv_msg() only tests netlink_net_capable(CAP_NET_ADMIN) against the netns user_ns, or can send through an already-installed IPsec policy.
- UI:NUser interaction, none
- The attacker registers the buffer with IORING_REGISTER_BUFFERS, submits SEND_ZC, and if needed installs the XFRM state/policy; no other user must open a file, mount a volume, or otherwise act.
- S:UScope, unchanged
- esp_ssg_unref()'s extra put_page() corrupts host kernel page refcounts. That is a conventional local privilege escalation inside the same kernel, not a KVM/Xen guest-to-host or IOMMU-scope change.
- C:HConfidentiality impact, high
- After the out-of-place transform, esp_ssg_unref() calls skb_page_unref() on every source sg page past skb->data. Those pages were attached by io_sg_from_iter() without a per-frag get_page(), so the extra put underflows the refcount of still-mapped IORING_REGISTER_BUFFERS pages and frees memory the attacker can read.
- I:HIntegrity impact, high
- The same extra skb_page_unref() frees registered-buffer pages that remain in the io_uring bvec and the attacker's userspace mapping, so the page can be reallocated and overwritten, giving an arbitrary write and control-flow hijack.
- A:HAvailability impact, high
- The extra put_page() on managed frag pages underflows the page refcount and frees a page still in use, which oopses with bad page state even when the use-after-free is not turned into a full memory-corruption exploit.