# CVE-2026-90301: ocfs2: o2hb: quiesce negotiate handlers and timeout work

> A race condition in the Linux kernel OCFS2 heartbeat module allows a peer to trigger a use-after-free or crash during region setup or teardown.

- **Severity:** High 8.1 (`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 17 Sep 2026
- **Updated:** 21 Oct 2026
- **Also known as:** AZL-102569, BELL-CVE-2026-90301, DEBIAN-CVE-2026-90301, GHSA-q5wj-37wf-cq7c, UBUNTU-CVE-2026-90301

## What is CVE-2026-90301?

CVE-2026-90301 is a high-severity vulnerability in Linux, published on 17 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: o2hb: quiesce negotiate handlers and timeout work

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

## Which versions are affected by CVE-2026-90301?


## How do I fix CVE-2026-90301?

Apply the vendor's patch.

## Is CVE-2026-90301 being exploited?

There is no known exploitation of CVE-2026-90301 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-90301 and fix it if it is affected.

What it is: CVE-2026-90301 is a high-severity vulnerability in Linux, published on 17 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-90301 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-90301/ (Markdown: https://insights.sbomify.com/CVE-2026-90301/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-90301
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-90301
- OSV: https://osv.dev/vulnerability/CVE-2026-90301

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-90301/
Summaries are generated and may contain mistakes; the official description above is the record.