Baokun Li 89602de9a2 quota: fix dqput() to follow the guarantees dquot_srcu should provide
[ Upstream commit dabc8b20756601b9e1cc85a81d47d3f98ed4d13a ]

The dquot_mark_dquot_dirty() using dquot references from the inode
should be protected by dquot_srcu. quota_off code takes care to call
synchronize_srcu(&dquot_srcu) to not drop dquot references while they
are used by other users. But dquot_transfer() breaks this assumption.
We call dquot_transfer() to drop the last reference of dquot and add
it to free_dquots, but there may still be other users using the dquot
at this time, as shown in the function graph below:

       cpu1              cpu2
_________________|_________________
wb_do_writeback         CHOWN(1)
 ...
  ext4_da_update_reserve_space
   dquot_claim_block
    ...
     dquot_mark_dquot_dirty // try to dirty old quota
      test_bit(DQ_ACTIVE_B, &dquot->dq_flags) // still ACTIVE
      if (test_bit(DQ_MOD_B, &dquot->dq_flags))
      // test no dirty, wait dq_list_lock
                    ...
                     dquot_transfer
                      __dquot_transfer
                      dqput_all(transfer_from) // rls old dquot
                       dqput // last dqput
                        dquot_release
                         clear_bit(DQ_ACTIVE_B, &dquot->dq_flags)
                        atomic_dec(&dquot->dq_count)
                        put_dquot_last(dquot)
                         list_add_tail(&dquot->dq_free, &free_dquots)
                         // add the dquot to free_dquots
      if (!test_and_set_bit(DQ_MOD_B, &dquot->dq_flags))
        add dqi_dirty_list // add released dquot to dirty_list

This can cause various issues, such as dquot being destroyed by
dqcache_shrink_scan() after being added to free_dquots, which can trigger
a UAF in dquot_mark_dquot_dirty(); or after dquot is added to free_dquots
and then to dirty_list, it is added to free_dquots again after
dquot_writeback_dquots() is executed, which causes the free_dquots list to
be corrupted and triggers a UAF when dqcache_shrink_scan() is called for
freeing dquot twice.

As Honza said, we need to fix dquot_transfer() to follow the guarantees
dquot_srcu should provide. But calling synchronize_srcu() directly from
dquot_transfer() is too expensive (and mostly unnecessary). So we add
dquot whose last reference should be dropped to the new global dquot
list releasing_dquots, and then queue work item which would call
synchronize_srcu() and after that perform the final cleanup of all the
dquots on releasing_dquots.

Fixes: 4580b30ea887 ("quota: Do not dirty bad dquots")
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Message-Id: <20230630110822.3881712-5-libaokun1@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19 12:22:35 +02:00
..
2022-08-17 14:24:07 +02:00
2023-06-21 15:59:18 +02:00
2021-08-19 09:02:55 +09:00
2022-07-02 16:41:14 +02:00
2023-08-11 15:13:58 +02:00
2021-08-26 22:28:02 +02:00
2022-06-09 10:22:55 +02:00
2021-12-29 12:28:59 +01:00
2023-08-30 16:18:19 +02:00
2023-08-30 16:18:19 +02:00
2023-07-23 13:46:48 +02:00
2023-05-17 11:50:14 +02:00
2021-08-19 09:02:55 +09:00
2023-02-22 12:57:05 +01:00
2023-08-30 16:18:19 +02:00
2023-08-30 16:18:19 +02:00
2022-12-14 11:37:31 +01:00
2023-01-12 11:58:47 +01:00
2022-07-02 16:41:17 +02:00
2022-07-12 16:35:08 +02:00
2021-12-14 10:57:15 +01:00