CVE-2023-53618 Affecting perf package, versions *


Severity

Recommended
low

Based on CentOS security rating.

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS7-PERF-13454451
  • published8 Oct 2025
  • disclosed7 Oct 2025

Introduced: 7 Oct 2025

NewCVE-2023-53618  (opens in a new tab)

How to fix?

There is no fixed version for Centos:7 perf.

NVD Description

Note: Versions mentioned in the description apply only to the upstream perf package and not the perf package as distributed by Centos. See How to fix? for Centos:7 relevant fixed versions and status.

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

btrfs: reject invalid reloc tree root keys with stack dump

[BUG] Syzbot reported a crash that an ASSERT() got triggered inside prepare_to_merge().

That ASSERT() makes sure the reloc tree is properly pointed back by its subvolume tree.

[CAUSE] After more debugging output, it turns out we had an invalid reloc tree:

BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17

Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM, QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.

But reloc trees can only exist for subvolumes, as for non-subvolume trees, we just COW the involved tree block, no need to create a reloc tree since those tree blocks won't be shared with other trees.

Only subvolumes tree can share tree blocks with other trees (thus they have BTRFS_ROOT_SHAREABLE flag).

Thus this new debug output proves my previous assumption that corrupted on-disk data can trigger that ASSERT().

[FIX] Besides the dedicated fix and the graceful exit, also let tree-checker to check such root keys, to make sure reloc trees can only exist for subvolumes.

CVSS Base Scores

version 3.1