CVE-2024-56759

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

btrfs: fix use-after-free when COWing tree bock and tracing is enabled

When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free.

Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there.

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/44f52bbe96dfdbe4aca3818a2534520082a07040
• https://git.kernel.org/stable/c/526ff5b27f090fb15040471f892cd2c9899ce314
• https://git.kernel.org/stable/c/66376f1a73cba57fd0af2631d7888605b738e499
• https://git.kernel.org/stable/c/9a466b8693b9add05de99af00c7bdff8259ecf19
• https://git.kernel.org/stable/c/ba5120a2fb5f23b4d39d302e181aa5d4e28a90d1
• https://git.kernel.org/stable/c/c3a403d8ce36f5a809a492581de5ad17843e4701