CVE-2024-57849 is a recently resolved vulnerability in the Linux kernel affecting the IBM s390 mainframe CPU measurement sampling facility (*cpum_sf*). The bug could let kernel code access already-freed memory when a CPU is hot-removed (hotplugged out) while a performance sample event is still active. This “use-after-free” condition can result in reading invalid or stale data, possibly leading to crashes or data leaks.

In this post, I’ll break down how the problem happens, show code snippets, detail a possible exploitation scenario, and share references to original sources. No advanced jargon—just a step-by-step explanation.

1. The Bug: What Went Wrong

The IBM s390’s CPU measurement sampling facility (CPUMF) keeps “sampling data buffers” (SDBs) per CPU. If a CPU is unplugged while a sampling event is active, two different kernel components (the s390 sampling handler and the generic kernel performance subsystem) both try to clean up the event—but out of sync.

Sequence

- The s390 PMU handler (cpum_sf) frees the per-CPU sampling buffers during CPU removal, *before* the kernel's perf event system has removed the event.
- Later, the perf event system removes the event and tries to read out any last samples from those same SDBs, which have already been freed.

This causes a classic use-after-free vulnerability

- The freed memory might have been reassigned or zeroed, so any data read may be garbage, or in rare a case, sensitive leaked kernel data.

s390 cpu removal

s390_pmu_sf_offline_cpu()
  └── cpusf_pmu_setup()
        └── setup_pmc_cpu()
              └── deallocate_buffers()    <-- Frees sampling buffers

Perf event removal

perf_event_exit_cpu()
  └── perf_event_exit_cpu_context()
        └── __perf_event_exit_context()
              └── __perf_remove_from_context()
                    └── event_sched_out()
                          └── cpumsf_pmu_del()
                                └── cpumsf_pmu_stop()
                                      └── hw_perf_event_update()   <-- Reads freed buffers

3. The Patch: How It Was Fixed

To fix the bug, the kernel now checks a reserved flag (PMU_F_RESERVED) before attempting to read the SDBs when cleaning up.

Patch Snippet (C)

void cpumsf_pmu_stop(struct perf_event *event, int flags)
{
    struct s390_cpu_pmu *cpumf = to_s390_pmu(event->pmu);
    // Only update if SDBs are still valid
    if (cpumf->flags & PMU_F_RESERVED)
        hw_perf_event_update(event, &event->hw, event->oncpu);
}

(Note: The actual code may differ, this is for illustration.)

4. Proof-of-Concept (POC) Exploit

A local user with the ability to create perf events might be able to crash the system or read invalid kernel memory by scripting CPU hotplug with active sampling.

Example POC workflow (requires root)

# Launch a perf record process on an s390 system:
perf record -e cpu-migrations -C 1 sleep 100 &

# (As root) Hot-remove CPU 1 while perf is sampling
echo  > /sys/devices/system/cpu/cpu1/online

Possible Result: Kernel oops, invalid access, or garbage data collected (kernel leaks depend on timing and memory reuse).

NOTE: This is for educational illustration only. Do *not* test on production systems.

5. Impact

- Systems Affected: Linux kernels on s390 (IBM mainframes) with PMU sampling and CPU hotplug support.

Attacker Requirements: Typically, local access with rights to use perf_event_open.

- Potential Dangers: Data leakage, system instability, privilege escalation (theoretically, if exploitably corrupted kernel data is used elsewhere).

Upstream Patch:

linux s390/cpum_sf: Handle CPU hotplug remove during sampling (kernel.org)

Discussion Thread:

LKML: s390: fix use after free in PMU hotplug path

CVE Record:

CVE-2024-57849 at NVD (when available)

Summary

CVE-2024-57849 is a use-after-free vulnerability in the Linux kernel’s s390 performance sampling that arises during CPU hotplug removal. The fix is a straightforward flag check ensuring freed buffers are never reused. While specialized and not remotely exploitable, it’s important for mainframe admins and kernel devs to be aware and patch.


*Feel free to ask for more code examples or an even deeper walk-through!*

Timeline

Published on: 01/11/2025 15:15:07 UTC
Last modified on: 05/04/2025 10:05:27 UTC