Look up another CVE · open CVE-2026-43249 in the interactive tracker
CVE-2026-43249
9p/xen: protect xen_9pfs_front_free against concurrent calls
Published 2026-05-06 (5 months ago) by the Linux kernel CNA. Subsystem net/9p. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-43249 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 | fixed | 6.12.85-1 | Update the kernel and reboot. Fixed in 6.12.85-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.19.6-1 | Update the kernel and reboot. Fixed in 6.19.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.19.6-1 | Update the kernel and reboot. Fixed in 6.19.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [ 27.052418] Call Trace: [ 27.052420] <TASK> [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] </TASK> [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]---
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/9p/trans_xen.c
- What this is
- 9P FILE SYSTEMMAINTAINERS section matched on net/9p/ · v9fs@lists.linux.dev · Maintained
- Kernel module
- 9pnet_xen
Check it on the machine
grep -wE 'CONFIG_NET_9P|CONFIG_NET_9P_XEN' /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 9pnet_xenPrints 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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, i386/686, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_NET_9P, CONFIG_NET_9P_XEN
- 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-05-06 (5 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.38%, higher than 30.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/9p
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.3 | 6.12.75 | a5d00dff9711 |
| 6.3 | 6.18.16 | 59e770749257 |
| 6.3 | 6.19.6 | bf841d43f7a3 |
| 6.3 | 7.0 | ce8ded2e61f4 |
| 4.14.308 | 0 | 0 |
| 4.19.276 | 0 | 0 |
| 5.4.235 | 0 | 0 |
| 5.10.173 | 0 | 0 |
| 5.15.100 | 0 | 0 |
| 6.1.18 | 0 | 0 |
| 6.2.5 | 0 | 0 |
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:AAttack vector, adjacent network
- The vulnerable 9p Xen frontend is reached through Xenbus/backend state changes from a paired Xen backend or service domain on the same host/logical I/O fabric. It is not directly routable over IP, but it is reachable across an adjacent inter-domain channel.
- AC:LAttack complexity, low
- A malicious backend can repeatedly queue the state transitions/removal paths that lead to concurrent or repeated xen_9pfs_front_free() calls. The trigger does not depend on conditions outside the attacker-controlled backend notification sequence.
- PR:NPrivileges required, none
- No privileges in the vulnerable guest are required; the guest frontend accepts the triggering state changes from its configured backend via Xenstore. Control of the backend is the attack position rather than a credential inside the target Linux kernel.
- UI:NUser interaction, none
- No victim user action is needed after the Xen 9pfs frontend device is present and bound. Backend state changes are processed asynchronously by xenwatch.
- S:UScope, unchanged
- The corrupted objects and resulting crash/code-execution risk are within the same guest Linux kernel running the vulnerable frontend. The issue does not demonstrate a guest-to-host or hypervisor escape.
- C:HConfidentiality impact, high
- This is kernel heap memory corruption via double-free of frontend state and associated ring resources. Such corruption can plausibly be shaped into use-after-free/freelist manipulation and arbitrary kernel memory disclosure, so the higher impact is warranted.
- I:HIntegrity impact, high
- The double-free can corrupt kernel allocator metadata or free a reallocated object, giving a plausible path to arbitrary write or control-flow compromise. Under the required uncertainty rule, this is scored as high integrity impact.
- A:HAvailability impact, high
- The reported failure is a general protection fault in xenwatch from dereferencing poisoned freed memory. A malicious backend can crash the guest kernel, causing high availability impact.