LinuxのLinux Kernelにおける不特定の脆弱性
タイトル LinuxのLinux Kernelにおける不特定の脆弱性
概要

Linuxカーネルにおいて、以下の脆弱性が修正されました。liveupdateのluo_file構造体に関連するretrieve()の状態管理に関する問題です。LUOはLUOファイルに対する成功したretrieve試行を追跡し、同じファイルの複数回のretrieveを回避するために実装されています。複数回のretrieveは問題を引き起こします。一度ファイルが取得されると、直列化されたデータ構造が解放されている可能性が高く、ファイルの状態がコードの期待する状態と大きく異なるためです。struct luo_fileのretrieve状態はブール値で追跡され、完了コールバックに渡されて実行済みの作業および残された作業を認識します。この仕組みは取得成功時には正常に機能します。しかし失敗した場合、luo_retrieve_file()は即座にエラーを返し、retrieve試行の有無やエラーコードを記録しません。そのため、ユーザースペースにはエラーになったLIVEUPDATE_SESSION_RETRIEVE_FD ioctlが返されますが、再試行を防止できません。この再試行は前述の理由で問題を引き起こします。ファイルの状態がretrieveロジックの通常の期待と大きく異なり、直列化データ構造の一部がすでに解放されている状態だからです。これらにアクセスしたり再度解放しようとすると問題が発生します。例えば、memfdが10個のフォリオのうち8個を復元し、9個目で失敗した場合、その後のretrieve試行は最初のフォリオに対して再度kho_restore_folio()を呼び出そうとし、それは無効な操作として警告を引き起こします。再試行に加え、finish()も問題を生じさせます。失敗時にluo_file内のretrievedフラグは変更されないため、セッション終了時のfinish()呼び出しはretrieve未試行と判断し、存在しない可能性のあるデータ構造にアクセスまたは解放を試み、再試行と同様の問題が発生します。retrieveを安全に再試行する方法は存在しません。エラーを記憶し、再試行時にはそのエラーを直接返す必要があります。またこの状態コードをfinish()に渡して適切な処理を可能にします。この改善はブール値を整数に変更することで実現され、値が0ならretrieve未試行、正の値は成功、負の値は失敗かつそのエラーコードを示します。

想定される影響 ・当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 ・当該ソフトウェアが扱う情報について、書き換えは発生しません。 ・当該ソフトウェアが完全に停止する可能性があります。 
対策

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。

公表日 2026年5月13日0:00
登録日 2026年6月29日11:19
最終更新日 2026年6月29日11:19
CVSS3.0 : 警告
スコア 5.5
ベクター CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
影響を受けるシステム
Linux
Linux Kernel 6.19 以上 6.19.9 未満
Linux Kernel 7.0
CVE (情報セキュリティ 共通脆弱性識別子)
CWE (共通脆弱性タイプ一覧)
その他
変更履歴
No 変更内容 変更日
1 [2026年06月29日]
  掲載
2026年6月29日11:19

NVD脆弱性情報
CVE-2026-43489
概要

In the Linux kernel, the following vulnerability has been resolved:

liveupdate: luo_file: remember retrieve() status

LUO keeps track of successful retrieve attempts on a LUO file. It does so
to avoid multiple retrievals of the same file. Multiple retrievals cause
problems because once the file is retrieved, the serialized data
structures are likely freed and the file is likely in a very different
state from what the code expects.

The retrieve boolean in struct luo_file keeps track of this, and is passed
to the finish callback so it knows what work was already done and what it
has left to do.

All this works well when retrieve succeeds. When it fails,
luo_retrieve_file() returns the error immediately, without ever storing
anywhere that a retrieve was attempted or what its error code was. This
results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace,
but nothing prevents it from trying this again.

The retry is problematic for much of the same reasons listed above. The
file is likely in a very different state than what the retrieve logic
normally expects, and it might even have freed some serialization data
structures. Attempting to access them or free them again is going to
break things.

For example, if memfd managed to restore 8 of its 10 folios, but fails on
the 9th, a subsequent retrieve attempt will try to call
kho_restore_folio() on the first folio again, and that will fail with a
warning since it is an invalid operation.

Apart from the retry, finish() also breaks. Since on failure the
retrieved bool in luo_file is never touched, the finish() call on session
close will tell the file handler that retrieve was never attempted, and it
will try to access or free the data structures that might not exist, much
in the same way as the retry attempt.

There is no sane way of attempting the retrieve again. Remember the error
retrieve returned and directly return it on a retry. Also pass this
status code to finish() so it can make the right decision on the work it
needs to do.

This is done by changing the bool to an integer. A value of 0 means
retrieve was never attempted, a positive value means it succeeded, and a
negative value means it failed and the error code is the value.

公表日 2026年5月14日1:16
登録日 2026年5月15日4:21
最終更新日 2026年5月14日1:16
関連情報、対策とツール
共通脆弱性一覧