CVE-2022-50126

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

jbd2: fix assertion jh->b_frozen_data == NULL failure when journal aborted

Following process will fail assertion jh->b_frozen_data == NULL in jbd2_journal_dirty_metadata():

               jbd2_journal_commit_transaction

unlink(dir/a) jh->b_transaction = trans1 jh->b_jlist = BJ_Metadata journal->j_running_transaction = NULL trans1->t_state = T_COMMIT unlink(dir/b) handle->h_trans = trans2 do_get_write_access jh->b_modified = 0 jh->b_frozen_data = frozen_buffer jh->b_next_transaction = trans2 jbd2_journal_dirty_metadata is_handle_aborted is_journal_aborted // return false

       --> jbd2 abort <--

                 while (commit_transaction->t_buffers)
                  if (is_journal_aborted)
                   jbd2_journal_refile_buffer
                    __jbd2_journal_refile_buffer
                     WRITE_ONCE(jh->b_transaction,
					jh->b_next_transaction)
                     WRITE_ONCE(jh->b_next_transaction, NULL)
                     __jbd2_journal_file_buffer(jh, BJ_Reserved)
    J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure !

The reproducer (See detail in [Link]) reports: ————[ cut here ]———— kernel BUG at fs/jbd2/transaction.c:1629! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 2 PID: 584 Comm: unlink Tainted: G W 5.19.0-rc6-00115-g4a57a8400075-dirty #697 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202 Call Trace: __ext4_handle_dirty_metadata+0xa0/0x290 ext4_handle_dirty_dirblock+0x10c/0x1d0 ext4_delete_entry+0x104/0x200 __ext4_unlink+0x22b/0x360 ext4_unlink+0x275/0x390 vfs_unlink+0x20b/0x4c0 do_unlinkat+0x42f/0x4c0 __x64_sys_unlink+0x37/0x50 do_syscall_64+0x35/0x80

After journal aborting, __jbd2_journal_refile_buffer() is executed with holding @jh->b_state_lock, we can fix it by moving is_handle_aborted() into the area protected by @jh->b_state_lock.

Weakness

The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

Affected Software

Extended Description

While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service. For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service.

Potential Mitigations

References

• https://git.kernel.org/stable/c/0f61c6dc4b714be9d79cf0782ca02ba01c1b7ac3
• https://git.kernel.org/stable/c/4a734f0869f970b8a9b65062ea40b09a5da9dba8
• https://git.kernel.org/stable/c/6073389db83b903678a0920554fa19f5bdc51c48
• https://git.kernel.org/stable/c/731c1662d838fe954c6759e3ee43229b0d928fe4
• https://git.kernel.org/stable/c/ddd896792e1718cb84c96f3e618270589b6886dc
• https://git.kernel.org/stable/c/e62f79827784f56499a50ea2e893c98317b5407b
• https://git.kernel.org/stable/c/f7161d0da975adc234161cd0641d0e484f5ce375
• https://git.kernel.org/stable/c/fa5b65d39332fef7a11ae99cb1f0696012a61527