Linux Kernel CVE-2024-0562: Race Causes Use-After-Free in Writeback End

A subtle timing bug deep in the Linux writeback code — a use‑after‑free in wb_inode_writeback_end() — can let an attacker trigger a kernel panic or sustained denial‑of‑service by removing a disk while writeback bookkeeping is still racing to schedule bandwidth‑estimation work; the flaw is tracked as CVE‑2024‑0562 and has been fixed in upstream kernels and backported by distributors. (git.codelinaro.org)

Background / Overview​

The Linux page writeback subsystem is responsible for flushing dirty pages from page cache to backing devices (disks, block devices, network storage, etc.). Within that subsystem, the backing device info (bdi) and its associated per‑device writeback structures (bdi_writeback / wb) track throttling and bandwidth estimation. When a block device is removed, the kernel must stop further writeback, wait for pending delayed work items to finish, and then tear down those per‑device structures safely. CVE‑2024‑0562 arises when that lifecycle sequencing is not properly synchronized: a delayed timer (bandwidth estimator) can be scheduled from wb_inode_writeback_end() after the bdi_writeback has been freed, producing a classic use‑after‑free that can crash or destabilize the kernel. (git.codelinaro.org)
This is an availability‑first kernel defect: local actors with permission to trigger disk removal or unmount sequences — for example, by removing a removable drive, ejecting a hot‑pluggable device, or manipulating device links from a moderately privileged process — can cause kernel crashes, panics, or persistent resource loss until the host is rebooted or the kernel structure is repaired. Vendor advisories and CVE records classify the bug as high severity and assign it a CVSS v3.1 vector consistent with local, low‑complexity attacks that can produce high impacts to confidentiality, integrity, and availability.

---

What exactly goes wrong: technical anatomy​

The affected functions and data structures​

• wb_inode_writeback_end(): a writeback callback invoked when page writeback completes for an inode. Part of the mm/page‑writeback.c implementation.
• bdi_unregister(): the code path that unregisters a backing device and waits for associated delayed work to finish before tearing down the bdi_writeback structure.
• bandwidth estimation delayed work / timer: periodic work that samples writeback activity to compute throttling/bandwidth numbers; this work is scheduled from multiple points in the writeback paths.

The bug occurs when wb_inode_writeback_end() schedules bandwidth estimation work after bdi_unregister() has already waited for and (in effect) freed the bdi_writeback. The scheduled timer later fires and tries to access memory that has been freed, which is undefined: it can produce kernel oopses, panic, or inconsistent internal state. (git.codelinaro.org)

Why this is a classic race/use‑after‑free​

• bdi_unregister() takes one logical path to stop and wait for delayed work, then frees per‑device structures.
• wb_inode_writeback_end(), which may execute in interrupt or other timing‑sensitive contexts, can schedule the bandwidth estimator without re‑checking whether the bdi_writeback is still valid.
• Because scheduling requires holding wb->work_lock and wb_inode_writeback_end() may run in interrupt context, the fix requires switching the lock to an irq‑safe lock and checking the liveness of the bdi_writeback before scheduling.
• Absent that check or the irq‑safe locking, the race window allows scheduling after free — the textbook precondition for UAF. (git.codelinaro.org)

---

Upstream fix and timeline​

The upstream kernel patch that corrects this behavior was authored by Khazhismel Kumykov and merged into the stable trees (commit f96b9f7c referencing f87904c0). The fix adds a liveness check before scheduling bandwidth estimation work and moves wb->work_lock to an irq‑safe lock so the check/schedule sequence is safe even when wb_inode_writeback_end() runs from interrupt context. The patch message and commit history are publicly available in the kernel stable tree. (git.codelinaro.org)
Vendor and distribution tracking for the defect appears across multiple advisories (Red Hat, Debian, Amazon Linux and others), and several distribution errata reference the same upstream patch and corrective commits. Red Hat included the issue in RHSA advisories and bug tracker entries; distributions have taken different approaches to backporting or marking the issue in their errata.

---

Who is affected and how to reason about attack surface​

Attack vector and prerequisites​

• Local attack only: Exploitation requires local capabilities. The vulnerability is not a remote network service bug.
• Privileges required: Low privileges are often sufficient — actions like ejecting a removable drive, unmounting, or otherwise causing a device removal sequence can be performed by non‑privileged or low‑privileged users in many desktop or multi‑user contexts (depending on system policy). Because the CVSS and vendor descriptions indicate low privilege required, operators should treat this as a meaningful local risk.
• Special conditions: The bug relies on a timing window during which wb_inode_writeback_end() schedules the estimator after bdi_unregister has finished; reproducing the timing is feasible on loaded systems or through carefully orchestrated device removal.

Consequences​

• Denial of Service: The primary practical impact is availability loss: each successful trigger can crash the kernel or cause persistent resource corruption requiring reboot, leading to total loss of service for affected workloads.
• Potential for memory corruption: While the primary evidence points to availability, UAFs in the kernel can sometimes be escalated into information disclosure or code execution under favorable conditions. No credible public reports indicate universal code execution exploitation in the wild for this CVE, but the theoretical risk exists; treat UAFs in kernel space as high‑risk.

---

Vendor response and distribution patching​

• Upstream (kernel.org): The commit described above is the canonical upstream fix. It is present in the stable trees and referenced by distribution advisories. (git.codelinaro.org)
• Red Hat: Red Hat assigned and tracked the issue (CVE‑2024‑0562) and published errata (RHSA) and bugzilla entries tied to the fix; operators running RHEL kernels should consult their Red Hat errata and install the updated kernel or vendor backport advised in RHSA‑2024:0412.
• Debian / Ubuntu / Other distros: Debian and Ubuntu lists include the CVE in their security tracking. Check your distribution’s security tracker for the specific kernel package that contains the backport and the kernel ABI you run.
• Cloud images / vendor kernels: Amazon Linux and other cloud vendors map and sometimes assign their own severities; Amazon publishes ALAS entries that list fixed kernel packages where applicable. If you run a vendor‑supplied cloud image or a custom kernel (for example, a vendor kernel with out‑of‑tree modules), confirm the mapping to the upstream commit and the vendor’s published package version.

Note: vendors sometimes disagree on severity and EPSS scoring; the technical facts are consistent but the operational guidance and patch cadence vary. If vendor advisory pages list your product, follow that vendor’s remediation guidance first.

---

Practical guidance for administrators and engineers​

Immediate actions (triage)​

• Inventory: Identify hosts running kernels that include the vulnerable code path. Look for kernels compiled from the upstream trees or vendor builds prior to the patch dates. Use vendor advisories (RHSA, ALAS, Ubuntu USN, etc.) to map your kernel packages to patched versions.
• Prioritize exposed systems: Systems where unprivileged users can remove devices, where removable media is common, or where multiple users share physical or virtual console access should be prioritized.
• Temporary mitigations:
• Restrict device removal and hot‑plug operations to admins only (udev rules, policy adjustments).
• Enforce stricter local access controls to prevent untrusted users from triggering device removal sequences.
• For high‑security hosts, consider disabling hot‑plug support or blocking the relevant sysfs interfaces from non‑privileged users until you can install a patched kernel.

Patch and verification steps​

• 1.) Obtain the vendor‑recommended kernel patch or package (kernel upgrade) and schedule deployment during maintenance windows. Vendors will publish which kernel package series contain the backport; use their package repositories.
• 2.) After upgrade, reboot hosts so the new kernel runs. Kernel memory‑safety fixes require a reboot to take effect.
• 3.) Post‑upgrade verification: confirm that the kernel commit (or vendor backport) is present in the running kernel via package changelogs, vendor advisory IDs in package metadata, or by verifying the kernel version/release string your distribution uses for security patches.

Detection and monitoring​

• Watch for kernel oops messages, stack traces mentioning mm/page‑writeback.c or wb_inode_writeback_end, and repeated soft‑lockups or anomalous writeback timers in dmesg and system logs.
• Deploy host‑level monitoring to detect unexpected reboots or kernel panics and correlate with device remove events (udev logs, auditd).
• For forensic analysis, collect vmcore or crash dumps following a kernel OOPS so that maintainers can validate whether a UAF triggered the incident.

---

Exploitability and risk assessment​

Public records and CVE aggregators classify CVE‑2024‑0562 as a high‑severity local kernel use‑after‑free (CVSS v3.1 7.8 in many databases), reflecting the combination of low privileges required and high potential impact on availability and integrity. There is no widely‑known remote exploit path; exploitation requires local access or the ability to cause device removal sequences. Consequently:

• For multi‑tenant servers, virtualization hosts, and desktops where users can attach/detach devices, the operational risk is meaningful.
• For single‑user, locked‑down server environments with no removable devices and strict local access control, the immediate attack surface is lower — though local privileged escalation paths or misconfigurations could still make the issue actionable.

Be mindful that kernel UAFs can sometimes be chained with other kernel bugs to achieve greater impact than the initial advisory suggests. The prudent stance is to assume high operational risk until patched.

---

Why the fix needed to be irq‑safe​

The upstream author’s commit explicitly changed wb->work_lock to an irq‑safe lock because wb_inode_writeback_end() may be invoked from interrupt context. Scheduling delayed work and checking liveness must be safe from interrupts; non‑irq‑safe locks held in code paths that can be interrupted can themselves create deadlocks or permit code to run without the intended synchronization guarantees. Converting to irq‑safe locking makes the liveness test reliably serializable with device teardown and the scheduler for delayed work. This is the technical reason upstream chose the defensive fix rather than more invasive rewrites. (git.codelinaro.org)

---

Detection signatures and log fingerprints to watch for​

• Kernel OOPS trace mentioning mm/page‑writeback.c, wb_inode_writeback_end, or bdi_writeback.
• Messages from the kernel showing “use after free” style stack traces or repeated panics that coincide with device removal.
• In multi‑tenant environments, coordinated device hot‑unplug events that precipitate host reboots.

If you see these signs, treat them as high priority — collect live logs, crash dumps, and host metadata and escalate to platform engineering or your vendor support channel.

---

Patching strategy and risk balancing​

• Test first: Because this touches the page writeback codepath, it can affect IO behavior. Test patched kernels on representative hosts—especially those running I/O‑heavy workloads—to validate that performance and throttling behavior remain acceptable.
• Staged rollout: For large fleets, stage the kernel upgrade in waves, validate stability and monitor for regressions, then complete rollout.
• Fallback planning: Ensure you have a rollback plan (snapshot, image restore, etc.) for cases where kernel updates cause unforeseen disruptions in a production environment.

---

Broader lessons and mitigation patteldevice teardown + timer/work coupling; when a component can schedule periodic or delayed work, robust liveness checks and irq‑safe locking are essential.​

• Operators should limit device hot‑plug capabilities to trusted actors and use SELinux/udev rules to restrict sysfs and device control interfaces when possible.
• Match kernel updates to vendor support/service windows — many vendors provide backports for LTS kernels, but you must verify the patch is included in the exact kernel ABI your distribution ships.

For enterprises, this CVE demonstrates why coordinated vulnerability management — mapping upstream commits to vendor packages, testing quickly, and deploying in a controlled but timely fashion — remains critical to maintaining platform availability.

---

Where the public record stands and notes on attribution​

Upstream kernel trees contain the authoritative commit and rationale; distribution advisories (Red Hat RHSA, Debian security tracker, Amazon ALAS, and others) list affected packages, backports, and errata. Several CVE aggregator services mirror the data and provide CVSS, EPSS and distribution mappings; use them as supplementary verification but rely on vendor advisories and the kernel commit for definitive fix details. (git.codelinaro.org)
Two uploaded internal research/collection files in our archive also discussed vendor attestations and kernel writeback topics relevant to this CVE and to how Microsoft and other vendors publish attestation data for Linux‑kernel CVEs — administrators should be aware of vendor‑scoped attestations when deciding which products are affected in a multi‑vendor environment.

---

Final assessment — strengths of the patch, remaining risks​

• Strengths
• The upstream fix is surgical and limited in scope: a liveness check and an irq‑safe locking change reduce the attack surface without overhauling the writeback subsystem.
• The fix landed in stable kernel trees and has been referenced by multiple vendor advisories — indicating rapid upstream-to‑vendor mapping. (git.codelinaro.org)
• Remaining risks
• Any local kernel UAF has theoretical potential for beyond‑DoS impacts; maintainers should be cautious until vendors confirm backports for all supported kernel branches.
• Heterogeneous environments with custom kernels or out‑of‑tree modules need manual verification that the backport is present.
• Detection remains noisy: kernel oopses caused by UAFs can be subtle, and root cause analysis may be required to tie a crash to this specific race rather than another writeback anomaly.

Where a vendor has not provided a backport you trust, treat the host as vulnerable until either a vendor kernel update is installed or you apply a vetted kernel from upstream/stable with the fix applied and tested.

---

Action checklist (concise)​

• Apply vendor kernel updates that include the upstream fix. Reboot after installation.
• If immediate patching is impossible:
• Restrict hot‑plug and device removal operations to administrators.
• Tighten local user permissions and udev/udevadm rules to prevent untrusted device removal.
• Enable more aggressive logging and crash collection around device hot‑plug events.
• Monitor dmesg and system logs for page‑writeback traces; collect crash dumps if a host OOPS occurs and escalate to vendor support.

---

CVE‑2024‑0562 is an instructive example: a small, timing‑centric change in a complex kernel subsystem produced a high‑impact availability problem that required a careful, minimal fix. Operators should treat the vulnerability seriously (particularly on shared, multi‑user, or removable‑media‑heavy systems), apply vendor updates promptly, and use the event as a prompt to validate device lifecycle and local access controls across their fleet.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center