CVE-2023-54134 in Linux
要約
〜によって VulDB • 2026年06月11日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
autofs: autofs_catatonic_modeにおけるwaitqueuesのメモリリークを修正
Syzkallerがメモリリークを検出しました：
BUG: memory leak unreferenced object 0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378
[<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593
[<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619
[<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897
[<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910
[<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline]
[<ffffffff81602a9c>] __x64_sys_ioctl+0x7c/0xb0 fs/ioctl.c:856
[<ffffffff81602a9c>] do_syscall_64+0x2d/0x90 arch/x86/entry/common.c:46
[<ffffffff81e0007a>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
autofs_wait()は、wait_ctrが0になるまでwaitqueuesを解放しません。 それ以外の場合、それらは失われます。
この場合、AUTOFS_IOC_EXPIRE_MULTI ioctlが行われ、autofs_wait()内で新しいwaitqueue構造体が割り当てられ、その初期wait_ctrは2になります。その後、wait_event_killable()が割り込まれ（-ERESTARTSYSを返す）、そのため'wq->name.name == NULL'条件が満たされない可能性があります。実際、この条件はautofs_wait_release()またはautofs_catatonic_mode()が呼び出されたときに満たされる可能性があり、さらに重要なのは、それらの場所でwait_ctrが減算されることです。autofs_wait()の終了後、wait_ctrは1に減算されます。その後、アンマウントプロセスが始まります：kill_sbはautofs_catatonic_mode()を呼び出し、これはwaitqueuesを解放すべきですが、使用カウンターを0に減算するだけで、これは正しい動作ではありません。
編集:imk この説明は正しくありません。expireの結果として行われるumountは、automountされたマウントのumountであり、autofsマウント自体ではありません。これらは通常、autofsファイルシステム内でマウントされたものがすべてexpireされた後に独立して発生します。すべてがexpireされていない場合、automountデーモンはマウントを配置したまま終了できます。しかし、両方のケースで行われるexpireは、結果ステータスでautofs_wait_release()を呼び出す通知につながります。問題となるケースは、automountデーモンの予期せぬ終了です。この場合、待機中のプロセスは、終了するかマウントがアンマウントされるまで、wake upされません。 編集終了: imk
したがって、catatonicモードでは、カウンターが0になるwaitqueuesを解放する必要があります。
編集: imk 当初、autofs_wait_release()とautofs_catatonic_mode()の呼び出しが相互排他的でないことを懸念していましたが、それはあり得ません（明らかに）、これらの関数のいずれかが呼び出されたときにキューエントリ（またはエントリ）がリストから削除されるため。結果として、waitエントリは、これらの関数のいずれか、またはautofs_wait()でwake upされたプロセスによって、呼び出しの順序に応じて解放されます。 編集終了: imk
If you want to get best quality of vulnerability data, you may have to visit VulDB.