原文

Linuxカーネルにおいて、以下の脆弱性が修正されました。ksmbdにおけるSMB2_CLOSEの後にSMB2_CANCELが発生した際の遅延されたfile_lockのuse-after-freeの問題です。コミットf580d27e8928（タイトル：「ksmbd: 二重SMB2_CANCEL時の遅延されたfile_lockのuse-after-freeを修正」）では、smb2_cancel()が状態がKSMBD_WORK_CANCELLEDの作業をスキップするように変更され、cancel_fnが二度呼ばれないようにしました。しかし、KSMBD_WORKは3つの状態（ACTIVE、CANCELLED、CLOSED）を持っており、CLOSEDの場合もファイルロックを解放する処理に到達します。SMB2_CLOSEがロックハンドルに対して行われると、set_close_state_blocked_works()が遅延作業の状態をKSMBD_WORK_CLOSEDに設定し、smb2_lock()のワーカーを起こします。ワーカーは非ACTIVEの状態で早期に終了し、locks_free_lock()でfile_lockを解放します。そして状態がKSMBD_WORK_CANCELLEDではないため、STATUS_RANGE_NOT_LOCKEDの分岐を取り、「goto out2」で終了します。この分岐はキャンセルされた場合と同様にrelease_async_work()をスキップします。このため、作業はconn-＞async_requestsに残り、解放されたfile_lockを指す有効なcancel_fn = smb2_remove_blocked_lockが設定されたままになります。その後、同じAsyncIdに対するSMB2_CANCELはKSMBD_WORK_CANCELLEDの状態のみをガードしています（状態はKSMBD_WORK_CLOSEDのため通過します）。そのため、smb2_cancel()は解放済みのfile_lockに対して再びcancel_fnを呼び出し、SMB2_CLOSEによって修正されたのと同じuse-after-freeが発生します。 問題の発生例は以下の通りです。BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel ＜- 2回目のSMB2_CANCELでcancel_fnが発火 handle_ksmbd_work 割り当て元は locks_alloc_lock ＜- smb2_lock であり、解放元は locks_free_lock ＜- smb2_lock（非ACTIVEの早期終了）です。対象は file_lock_cache（サイズ192）です。この問題はf580d27e8928を含むmainline 7.1-rc7で、KASANを有効にした認証済みSMBクライアントにて再現されました。二重のSMB2_CANCEL制御はすでにそのカーネルでは無効化されており、問題の原因はCLOSEトリガーにあります。cancel_fnが起動できるのはACTIVE状態の遅延作業のみであり、終端状態であるCANCELLEDおよびCLOSEDはsmb2_lock()の早期終了でfile_lockを解放し、release_async_work()をスキップします。したがって、非ACTIVEの作業はKSMBD_WORK_ACTIVEでガードし、スキップする必要があります。