CVE-2022-48733

Description

From CVE.org

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free after failure to create a snapshot At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore.

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

The following CVSS metrics and score provided are preliminary and subject to review.

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score7.87.87.8
Attack VectorLocalLocalLocal
Attack ComplexityLowLowLow
Privileges RequiredLowLowLow
User InteractionNoneNoneNone
ScopeUnchangedUnchangedUnchanged
ConfidentialityHighHighHigh
Integrity ImpactHighHighHigh
Availability ImpactHighHighHigh

Vector

Red Hat: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

NVD: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

cve.org: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Understanding the Weakness (CWE)

Integrity

Technical Impact: Modify Memory

The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.

Availability

Technical Impact: DoS: Crash, Exit, or Restart

If chunk consolidation occurs after the use of previously freed data, the process may crash when invalid data is used as chunk information.

Confidentiality

Technical Impact: Read Memory

Read operations on freed memory can sometimes leak sensitive information instead of causing a crash

Integrity,Confidentiality,Availability

Technical Impact: Execute Unauthorized Code or Commands

If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code. 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.

Frequently Asked Questions

Want to get errata notifications? Sign up here.