原文

Linuxカーネルにおいて、以下の脆弱性が解決されました。nilfs2では、範囲外のセグメント番号を持つCLEAN_SEGMENTS ioctlの拒否問題があります。Syzbotはnilfs_transaction_begin()でタスクがハングすることを報告しました。複数のタスクがnilfs2マウント上でchmod()を実行する間、143秒以上ns_segctor_semの読み取り権取得を待機してブロックされていました。情報として、タスクsyz.0.17:5918は143秒以上ブロックされています。コールトレースは以下の通りです。schedule+0x164/0x360、rwsem_down_read_slowpath+0x6d9/0x940、down_read+0x99/0x2e0、nilfs_transaction_begin+0x364/0x710(fs/nilfs2/segment.c:221)、nilfs_setattr+0x124/0x2c0(fs/nilfs2/inode.c:921)、notify_change+0xc1a/0xf40、chmod_common+0x273/0x4a0、do_fchmodat+0x12d/0x230です。ns_segctor_semを保持していたプロセスは、同時にNILFS_IOCTL_CLEAN_SEGMENTS呼び出し元であり、nilfs_sufile_updatev()からの要素ごとの警告を出力中にprintk内でスタックしていました。呼び出し元のスタックは、__nilfs_msg+0x373/0x450(fs/nilfs2/super.c:78)、nilfs_sufile_updatev+0x21c/0x6d0(fs/nilfs2/sufile.c:186)、nilfs_sufile_freev(fs/nilfs2/sufile.h:93 [inline])、nilfs_free_segments(fs/nilfs2/segment.c:1140 [inline])、nilfs_segctor_collect_blocks(fs/nilfs2/segment.c:1261 [inline])、nilfs_segctor_do_construct+0x1f55/0x76c0、nilfs_clean_segments+0x3bd/0xa50、nilfs_ioctl_clean_segments(fs/nilfs2/ioctl.c:922 [inline])、nilfs_ioctl+0x261f/0x2780です。根本原因は、ユーザーから提供されたセグメント番号がnilfs_clean_segments()が処理を開始する前に検証されていなかったことにあります。各segnumの範囲チェックは呼び出しチェーンの深い部分にあるnilfs_sufile_updatev()で行われ、不正なエントリごとにnilfs_warn()が発行されますが、その際にはsegctorロックとsufileのmi_semを保持しています。負荷が高くなり（複数マウントにまたがる繰り返し呼び出しによりグローバルprintk経路が飽和した場合）、累積するprintk遅延によってns_segctor_semが長時間保持されるため、hung_taskウォッチドッグが作動し、chmod()のように読み取りのためにns_segctor_semを必要とする同時処理がブロックされていました。修正内容は、nilfs_transaction_lock()を介してns_segctor_semを取得した直後にnilfs_clean_segments()内のkbufs[4]の内容を検証することです。ns_segctor_semを保持することで、ns_nsegmentsを変更可能なnilfs_ioctl_resize()との整合性の取れたチェックが可能になります。範囲外のセグメント番号は、セグメントのクリーン作業を開始する前に-EINVALで拒否されるため、問題のあるエントリがnilfs_sufile_updatev()内の要素単位の診断経路に到達しません。