Cloudanix VulnDB

CVE-2026-68357

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's watchdog timer handling can let freed memory be accessed again, which may crash the system or allow an attacker to run code with full system privileges.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability leaves a dangling pointer to a freed watchdog governor structure in the default_gov variable after watchdog_unregister_governor() is called on the current default, causing subsequent watchdog device registrations or reassignments to dereference the freed memory.

Why it matters to the business

Systems using custom watchdog governors may experience kernel instability, crashes, or potential code execution in kernel context, increasing downtime risk for servers, embedded devices, and appliances relying on watchdog timers for reliability.

How an attack unfolds

An attacker with the ability to load and unload a custom watchdog governor module that has been set as default_gov triggers the bug by unregistering it, leaving the pointer intact; subsequent watchdog device creation or governor fallback operations then access the freed memory, potentially leading to crashes or controlled memory corruption.

How to fix it

Apply the upstream fix that clears default_gov when the unregistered governor matches it; rebuild and deploy the patched kernel to all affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting the watchdog core source for the added default_gov clearing logic, then exercise governor registration/unregistration paths under test workloads to verify no dangling references remain.

Typical attack path

  1. Load a custom watchdog governor and configure it as the system default
  2. Trigger unregistration of that governor (via module unload or explicit API call)
  3. Cause creation of a new watchdog device or fallback on an existing device
  4. Trigger dereference of the dangling default_gov pointer to achieve UAF

How to detect it

Review kernel logs for oops/panic traces mentioning watchdog_unregister_governor or default_gov; inspect module load/unload events around watchdog devices; correlate with any custom governor usage in dmesg or system boot logs.

  • watchdog_unregister_governor
  • default_gov

What your security team should do

  • Prioritize kernel updates on all systems using watchdog governors within normal change windows given the 76-day publication age and low EPSS
  • Audit custom watchdog governor usage and avoid setting non-upstream governors as default where possible
  • Monitor for kernel oops or panic reports referencing watchdog governor structures

The record

In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.

Affected packages

Ecosystem Package Introduced Fixed