About CVE-2022-28796 – A design flaw was found in transaction[.]c on Linux (8th Apr 2022)

Preface: JBD2 is the kernel thread of the ext4 file system. It often experiences the shadow (BH_Shadow) state during its use, which can affect the system performance. To solve this problem, Alibaba Cloud Linux 2 provides an interface in version 4.19. 81-17.

Background:

  • Ext3 would call an allocator for each block
    A 100MB file would need to call the allocator 25600 times for each individual block in Ext3
  • Ext4 only calls the allocator once for each file
    In Ext4, the allocator is called only once to allocate the 25600 blocks

Ext4 uses 48-bit internal addressing, making it theoretically possible to allocate files up to 16 TiB on filesystems up to 1,000,000 TiB (1 EiB). Early implementations of ext4 were still limited to 16 TiB filesystems by some userland utilities, but as of 2011, e2fsprogs has directly supported the creation of >16TiB ext4 filesystems. As one example, Red Hat Enterprise Linux contractually supports ext4 filesystems only up to 50 TiB and recommends ext4 volumes no larger than 100 TiB.

Lustre is an open source parallel distributed file system (DFS) specialized for large-scale cluster computing. The name is a portmanteau of Linux and cluster. Lustre is used by many supercomputers and large multi-cluster sites. A large precent of supercomputers use Lustre file systems. LCOC (Lustre Cache on Client) provides a group of local cache. Each client has its own local cache based on SSD. For example, LCOC uses Ext4 (Samsung SSD 850 EVO 500GB) as local cache.

Vulnerability details: CVE-2022-28796 – jbd2_journal_wait_updates in fs/jbd2/transaction[.]c in the Linux kernel before 5.17.1 has a use-after-free caused by a transaction_t race condition.

In the case of traditional (use-after-free) vulnerabilities. Due to an absence of a locking mechanism, an attacker is able to create a race condition in the device mechanism and trigger a Use After Free vulnerability. But the developers discovered the following reasons.
jbd2_journal_wait_updates() is called with j_state_lock held in normal circumstances. But if there is a commit in progress, then this transaction might get committed by function (jbd2_journal_commit_transaction()). Finally freed via this function (jbd2_journal_free_transaction()) release j_state_lock.

Solution: Upgrade to 5.18-rc2

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.