原文

Linuxカーネルにおいて、以下の脆弱性が修正されました。audit: audit_queue上のskb_queue_len()リーダーのデータレース修正。複数のリーダーが、キューのロック保持やREAD_ONCE()の使用なしにskb_queue_len()を介してaudit_queue.qlenにアクセスしている一方で、kauditdはspinlockで保護されたWRITE_ONCE()を用いたskb_dequeue() → __skb_unlink()経路でこのフィールドへ書き込みを行っていました。これによりデータレースが発生していました。影響のあるすべてのskb_queue_len(&audit_queue)呼び出し箇所は以下の通りです。 - kauditd_thread()のwait_event_freezable()条件 - audit_receive_msg()のAUDIT_GETハンドラ（s.backlogの代入） - audit_receive()のbacklogチェック - audit_log_start()のbacklogチェックおよびpr_warn()。KCSANが報告した競合アクセスの例は以下の通りです。==================================================================BUG: KCSAN: data-race in audit_log_start / skb_dequeue4バイトの書き込み（タスク661、CPU57）: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x304バイトの読み取り（タスク36586、CPU1）: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0値の変化：0x00000001 -＞ 0x00000000==================================================================この競合を解消するために、内部でREAD_ONCE()を使用し、書き込み側で既に存在するWRITE_ONCE()書き込みと適切に対応するロックレスヘルパーskb_queue_len_lockless()へ切り替えました。[PM: 行長調整]