Look up another CVE · open CVE-2026-90301 in the interactive tracker
CVE-2026-90301
ocfs2: o2hb: quiesce negotiate handlers and timeout work
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem fs/ocfs2. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90301 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
Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that path: region lifecycle: late negotiate callback: 1. make_item() registers the 1. o2net_process_message() gets a region handlers before heartbeat handler for reg. dev_store() has built a 2. The callback runs after the lookup runnable heartbeat context. lock is dropped and dereferences reg. 2. A failed start or rmdir 3. An approve or timeout path tries to stops the heartbeat thread, queue reg's delayed work, or release quiesces existing work, and races the callback body after handler drops the final configfs ref. unregister. 3. region_release() must drain 4. The callback or delayed work can handler-visible o2net rx work outlive reg unless lifecycle code before freeing reg. keeps the region non-armable and drains the active-or-destroying o2net workqueue. Validation reproduced this kernel report: KASAN slab-use-after-free in __run_timers+0x22c/0x5b0 Write of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600
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.
fs/ocfs2/cluster/heartbeat.c
fs/ocfs2/cluster/tcp.c
fs/ocfs2/cluster/tcp.h
- What this is
- ORACLE CLUSTER FILESYSTEM 2 (OCFS2)MAINTAINERS section matched on fs/ocfs2/ · ocfs2-devel@lists.linux.dev · Supported
- Kernel module
- ocfs2_nodemanager
Check it on the machine
grep -w CONFIG_OCFS2_FS /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 ocfs2_nodemanagerPrints 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.
- bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_OCFS2_FS
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
- 8.1 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.53%, higher than 43.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/ocfs2
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.7 | 6.18.57 | 9d44822ba34d |
| 4.7 | 7.2.6 | b5a2907bdece |
| 4.7 | 7.3 | 011291b70ba4 |
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:NAttack vector, network
- O2HB_NEGO_APPROVE_MSG and O2HB_NEGO_TIMEOUT_MSG arrive as o2net TCP payloads. o2net_data_ready queues sc_rx_work; o2net_rx_until_empty → o2net_advance_rx → o2net_process_message looks up the handler by msg_type and hr_key and calls o2hb_nego_approve_handler or o2hb_nego_timeout_handler, so the peer supplies the triggering bytes on a routable IPv4 TCP session.
- AC:HAttack complexity, high
- Memory corruption requires the region to be between o2hb_heartbeat_group_make_item() publishing handlers (hr_steady_iterations still 0, delayed work uninitialized) and INIT_DELAYED_WORK in o2hb_region_dev_store(), or o2net_handler_get() racing o2hb_region_release()'s kfree. The peer sends NEGO_APPROVE but cannot mkdir/rmdir the configfs region that opens those windows.
- PR:NPrivileges required, none
- o2net_accept_one admits the TCP peer after o2nm_get_node_by_ip() and o2hb_check_node_heartbeating_from_callback(); o2net_check_handshake only compares protocol version and idle/keepalive/heartbeat timeouts. No user login or capability check runs before o2hb_nego_approve_handler, so no account on the victim is required.
- UI:NUser interaction, none
- Once an o2net session exists, the attacker triggers the bug by sending O2HB_NEGO_APPROVE_MSG. Configfs heartbeat-region create or rmdir is cluster bring-up or shutdown timing, not a victim action such as mounting a filesystem or opening a file.
- S:UScope, unchanged
- The UAF writes the freed o2hb_region from o2hb_arm_timeout() and __run_timers stay in the host kernel on that cluster node and do not cross a guest-to-host, VM, or IOMMU boundary.
- C:HConfidentiality impact, high
- KASAN reported a slab-use-after-free of the o2hb_region allocated by o2hb_heartbeat_group_make_item. o2hb_nego_timeout_handler still reads hr_nego_node_bitmap and config_item_name after free, and reclaiming the slab gives the attacker the freed object contents, enabling disclosure of adjacent kernel memory.
- I:HIntegrity impact, high
- o2hb_nego_approve_handler calls o2hb_arm_timeout(), which schedule_delayed_work's hr_write_timeout_work and hr_nego_timeout_work on a not-yet-initialized or already-freed o2hb_region. The reproduced bug is an 8-byte write in __run_timers on that freed object, a UAF write that can hijack kernel control flow.
- A:HAvailability impact, high
- The UAF write in __run_timers runs from run_timer_softirq and oopses the node. If the wrongly armed hr_write_timeout_work fires, o2hb_write_timeout() also calls o2quo_disk_timeout() → o2quo_fence_self(), fencing the victim.