CVE-2026-93243 in Linux
要約
〜によって VulDB • 2026年09月24日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
mm/secretmem: ロックされたページを適切にアカウント処理する
secretmemは、メモリをmlock()されているものとして扱い、RLIMIT_MEMLOCK制限によって制限されるかのようにしてfolios（大きなページの単位）をアカウント処理します。
しかしながら、foliosはunevictable（回収不能）であり、inodeがevicted（解放/削除）されるまでその状態が続きます。これにより通常のmlock()のセマンティクスが失われます。つまり、foliosのマッピングとアンマッピングを行っても、AS_UNEVICTABLEフラグに依存しているためPG_mlockedとは無関係で、unevictableな状態はクリアされません。
そのため、ユーザーはRLIMIT_MEMLOCK制限を簡単に回避できます。単にマップしてからアンマップするだけで、VmLck（ロック済みメモリ量）からsecretmemの範囲がカウントされなくなります。さらに悪質なことに、foliosはプロセスのRSS（Resident Set Size：実効セットサイズ）に含まれないため、OOMキラーはそのプロセスを終了させるべきことを認識しません。
繰り返しマッピング/アンマッピングを行う（またはforkを実行する）と、unevictableなfoliosによって利用可能なシステムメモリがすべて消費され、システムの不安定化を引き起こす可能性があります。
secretmemファイルディスクリプタはプロセス間やforkを通じて渡せるため、per-process（プロセス単位）の制限では意味を成しません。そのため、io_uring、perf、skbuff、iommufd、xdpによって確立された先例に従い、ロック済みページの数をuser_struct->locked_vmで追跡します。
実際にはinodeの有効期間が追跡対象であるため、RLIMIT_MEMLOCKはper-processではなくper-user（ユーザー単位）で適用されるべきです。したがって、CAP_IPC_LOCK権限を持つユーザーに対するこの回避策を削除するのは意味がありません。そのため、この回避策を削除します。
マッピングをmlock()されているとしてマークし続ける理由はありません。これは誤解を招くものであり、ライフサイクルは正しく処理されるようになったためです。したがって、これも削除します。
secretmemはいかなる形式のtruncation（切り詰め：hole punchingを含む）をサポートしておらず、foliosもunreclaimable（回収不能）であるため、foliosのアカウント処理はフォルト発生時に行い、inode破棄時にアンアカウント処理すれば十分です。
__secretmem_account_pages()はio_uringなどが使用するコードとほぼ重複していますが、これはバックポートが必要なバグ修正のため、デディプリケーション（コード共通化）の試みは後続のパッチに委ねます。
test_mlock_limit()テストではmmap()時にmlock_future_ok()のアサートを行っていましたが、この関数は削除されたため、修正のためにテスト自体を削除します。新しいテストは別途アップストリームへ送信されます。
If you want to get best quality of vulnerability data, you may have to visit VulDB.