Linux 7.4 on 思いつきそうで思いつかなくていたときに

PAN-OS CVE-2026-0257 の悪用継続、Claude Code 製パッチの再設計 RFC、Linux-libre 7.3、EDAC ドライバの引退、Siemens Software Center の脆弱性悪用（2026/10/21 Linux・OSSトレンド）

Wed, 21 Oct 2026 00:00:00 +0900

はじめに

パッチは書いて終わりではなく、確かめて届けるまでが修正です。今回の5本は、どれも「書いた後」の話として読めます。2026年5月に修正が出た穴は、修正を当てていない機器で攻撃され続けています。Linus Torvalds 氏が AI を使って書いたカーネルのパッチは、Kiryl Shutsemau 氏の手で18本の RFC に作り直されました。AI が生成する修正の増加は、古いドライバがメンテナ不在になる場面にも現れています。

5本に共通点を見るのは、あくまで書き手の考察です。Linux 7.3 は10月18日（米国時間）に正式リリースされ、7.4 のマージウィンドウが開いています。動画で一次情報と食い違った発言は、各節末の「動画の訂正」にまとめました。

1. PAN-OS GlobalProtect の CVE-2026-0257 — 5月に修正が出た穴が、10月も狙われている

CVE-2026-0257 は、Palo Alto Networks の PAN-OS で GlobalProtect のポータルまたはゲートウェイを使っている環境の脆弱性です。アドバイザリの公開は2026年5月13日です。影響を受けるのは、認証オーバーライドクッキーが有効で、特定の証明書構成がある場合です。分類は CWE-565（Reliance on Cookies without Validation and Integrity Checking）です。Qilin による悪用は7月22日の記事で扱いました。

Unit 42 の10月19日の更新

Unit 42 のブリーフは、10月19日（米国太平洋時間16時）に、ランサムウェアグループの活動を加えて更新されました。10月20日にも、確認と対策の案内を足す更新があります。10月19日の更新によれば、Unit 42 は Spikey Scorpius（別名 Qilin）と Tarnished Scorpius（別名 Inc）による悪用の試みを引き続き観測しています。Settra ランサムウェアを使う攻撃者による悪用は、Unit 42 自身の帰属ではなく、“public reporting” として別に紹介されています。

偽造の仕組みと深刻度

Rapid7 のブログによれば、クッキーの暗号化用の証明書をポータルやゲートウェイの HTTPS など他の機能と使い回していると、未認証の遠隔攻撃者が公開鍵を取得し、任意の認証オーバーライドクッキーを偽造して暗号化できます。Rapid7 の研究部門が作った PoC は5月29日に公開され、同日、CISA の Known Exploited Vulnerabilities カタログにも追加されています。

CVSS は版を分けて読む必要があります。

Palo Alto のアドバイザリで 4.7（中）から 7.8（高）に変わったのは、CVSS v4.0 の脅威込みスコア（CVSS-BT）です。悪用状況を反映して、5月29日に更新されました。v4.0 の基本スコア（CVSS-B）は最初から 7.8 です
CVSS v3.1 の 9.1（Critical）は、NVD が付けた別のスコアです

侵入後の流れ

Arctic Wolf のブログは、2026年6月に調べた複数の侵入で、CVE-2026-0257 が初期侵入の経路だったと書いています。LSASS のプロセスメモリからの認証情報の取得、ntdsutil.exe による Active Directory データベースの複製、PsExec と RDP による横展開、Windows イベントログの消去が挙がっています。Microsoft Defender のリアルタイム保護は、一部の事例で、ランサムウェアの展開前に無効化されていました。Arctic Wolf は、侵入後の手口は被害者ごとに異なったとも書いています。

Unit 42 のブリーフの冒頭には、VPN セッションが確立したのは調べた機器の一部で、横展開は確認されていない、という6月からの文が残っています。一方、10月19日の更新節は、RDP と SMB での横展開を挙げ、VPN ゲートウェイから vCenter の管理アプライアンスに移った事例も報告しています。

対象と対策

対象は PAN-OS の 10.2・11.1・11.2・12.1 の一部の版と、サポートが切れた旧版です。Panorama と Cloud NGFW は影響を受けません。Prisma Access は 10.2 と 11.2 の一部が対象で、アップグレードは Palo Alto の予定に沿って進められています
修正版は、アドバイザリによれば、12.1.7 以降、11.2.12 以降、11.1.15 以降、10.2.18-h6 以降などです。系列と現在の版ごとの修正版は、アドバイザリの Product Status の表で確認します
修正版にすると、認証オーバーライドクッキーは安全な方法で作り直されるため、GlobalProtect の利用者は一度だけ再認証が必要です
すぐに上げられない場合の緩和策は2つあります。認証オーバーライドクッキー専用の証明書を新しく作る方法と、認証オーバーライドの設定を無効にする方法です。ポータルやゲートウェイの証明書を使い回してはいけません
確認には、Unit 42 の案内にあるように、GlobalProtect のログで、不審なホスト ID やデバイス名からの gateway-connected イベントを検索します

動画の訂正です。

動画では、10月の更新に「VPN セッションが確立したのは一部」「横展開は確認されていない」と書かれていると紹介しましたが、この2文は2026年6月9日版から残る冒頭の文です。10月19日の更新節は、RDP と SMB での横展開と vCenter への移動を報告しています（Unit 42 のブリーフ）。

2. Linus Torvalds の Claude Code 製パッチを、Kiryl Shutsemau 氏が18本の RFC に — 取り込みはまだ先

Meta 所属の Kiryl Shutsemau 氏が、10月19日（UTC）に、ページキャッシュを folio の参照カウントなしで読む RFC を linux-mm に投稿しました。Meta という会社の取り組みではなく、同氏個人の RFC です。カバーレターの件名は “[RFC PATCH 00/18] mm: read the page cache without folio references” です。

元になった Linus 氏のパッチ

Linus Torvalds 氏のブランチ noref-filemap-read-with-llm のコミットは、2026年10月10日付です。本文の Tools 節に、コード、テストプログラム、レビュー、本文の最初の下書きは、同氏の指示のもとで LLM のコーディングアシスタント（Claude Code）が行ったと書かれています。10月13日には、10本のパッチ（ブランチ rcu-free-v3）が LKML に投稿されています。

何を直すのか

カバーレターによれば、多くの CPU が同じファイルを少しずつ読むと、どの CPU も同じ folio の参照カウントを増減し、その cache line を奪い合います。RFC は、読み手がコピーする可能性のある folio の解放を、RCU の猶予期間の後まで遅らせて、参照カウントを不要にします。

18本の内訳は、カバーレターの shortlog で、Linus 氏が作者のものが7本、Shutsemau 氏が作者のものが11本です。Linus 氏の側の草案は、ブランチによって8本（10月10日）または10本（10月13日）で、7本とは別の数え方です。Shutsemau 氏のパッチにも、Linus 氏のパッチにも、Assisted-by: LLM の trailer が付いています。

設計の要点

フラグ PG_rcu_free は、読み込み時に、繰り返し読まれる（hot な）folio に立てます。ストリーミング読み込みなど、hot にならないデータは遅延の対象外です。フラグは 64 ビット環境だけで使えます
解放待ちのページが CPU あたり 4 MiB（4 KiB ページで 1024 ページ）を超え、さらにメモリが逼迫しているときに、猶予期間の短縮を要求して解放を急ぎます
待機中のページは、ゾーンごとのカウンタ NR_FREE_RCU_PAGES で数えます。OOM killer に処理を渡す前に待機分を解放して再試行する変更も含まれます
新しい読み方を止めるスイッチは、sysctl ではなく debugfs の lockless_page_cache_read で、RFC のパッチ18/18に含まれています。将来、削除される可能性があるとも書かれています
tmpfs の読み込みにも同じ仕組みを使います

測定結果

測定は、64 vCPU の KVM ゲストを AMD Threadripper 7975WX で動かし、CPU の脆弱性対策を既定のまま有効にして、7.3-rc7 を基準に行われています。64 スレッドで 16 バイトの pread() を行った結果は、カバーレターの値で次のとおりです。

ファイルシステム	基準（M reads/s）	RFC（M reads/s）	比
EXT4	15.0-15.7	68.9-70.1	約4.5倍
tmpfs	1.6-1.7	71-72	40倍超
XFS	11.3-11.4	20.4-20.5	約1.8倍

1スレッドの読み込みは、ほぼ変わりません（1.6-1.9 が 1.7-2.0）。カバーレターの Open 節には、未解決の点が挙がっています。待機中の folio は、その間どの cgroup にも計上されません。メモリのコンパクションへの影響は、まだ測っていません。書き込み可能にマップされたファイルでは、flush_dcache_page() を実装するアーキテクチャは従来の遅い経路を通ります。

取り込み状況

10月21日の時点で、torvalds/linux の master にこのシリーズは入っていません。RFC として投稿された段階で、議論が続いています。

動画の訂正です。

動画では、フラグを「ページキャッシュから外れたページに」立てると紹介しましたが、RFC では、読み込み時に、繰り返し読まれる folio に立てます。フラグの付いた folio が外れるときに、解放を猶予期間の後まで待たせる、という結果は動画のとおりです（カバーレターの 00/18）。

3. GNU Linux-libre 7.3 — 新しいドライバの blob 名を取り除く

GNU Linux-libre は、Linux カーネルから、ソースのない非自由なコンポーネントを取り除くプロジェクトです。7.3-gnu のアナウンスの日時は、10月19日 05:02:14 UTC です。Linux 7.3 のタグ（10月18日 23:14:58 UTC）の約6時間後にあたります。

今回の対象

アナウンスによれば、新しいドライバのうち、Tyr（Arm の Mali GPU 向け）、Morse Micro の mm81x（Wi-Fi）、NXP の Wi-Fi、Realtek の PHY で blob 名を掃除しました。Tyr は、カーネルの Kconfig で Arm Mali CSF 系 GPU 向けの Rust DRM ドライバとされています。Morse Micro の mm81x が対象とする Wi-Fi HaLow は、Wikipedia によれば IEEE 802.11ah の愛称で、1GHz 未満の帯域を使います。

既存のドライバでは、nova-core、amdgpu、adreno、rtw89、mt76 などで、新しく増えた blob 名を掃除しました。今回初めて対象になったのは新しいドライバの4件で、既存のドライバは増えた分の洗い直しです。nova-core は、カーネルの文書によれば、GPU System Processor（GSP）を持つ NVIDIA GPU 向けのドライバです。

何をするプロジェクトか

アナウンスは、ソースコードに見せかけた、または別ファイルで配られる非自由なコンポーネントを取り除き、それらを実行時に要求する処理と、それを指す文書も無効にする、と説明しています。取り除いたものの自由な代替を用意することはしない、という方針も書いています。取り除きの作業は、プロジェクトのページによれば、スクリプト deblob-main が担い、残りの検査には deblob-check を使います。

使う方法

プロジェクトのページには、Debian 系向けの Freesh（.deb）、Fedora や RHEL 系向けの RPM Freedom（.rpm）、PREEMPT_RT 付きの libeRTy（.deb）が載っています。7.3 のアナウンス時点では、ビルド済みのリリースは “available shortly” とされていました。FSF が推奨するディストリビューションには、Parabola、PureOS、Trisquel などがあります。どの版に追従できるかは、使うディストリビューションの案内で確認してください。

歴史

アナウンスによれば、Linux-libre は gNewSense の中で始まり、後に Jeff Moe 氏が引き継いで名付けました。2008年に FSF Latin America が維持するプロジェクトになり、2012年に GNU プロジェクトの一部になっています。Wikipedia は、Alexandre Oliva 氏をメンテナとしています。

動画の訂正はありません。

4. Linux 7.4 のマージウィンドウで、古い EDAC ドライバ4つがメンテナ不在に

Borislav Petkov 氏の EDAC の pull request が、Linus 氏に取り込まれました。マージコミットの日時は、2026年10月20日 18:14:43 UTC です。7.3 の後のマージウィンドウで入ったもので、v7.4-rc1 のタグは10月21日の時点でまだありません。マージウィンドウのほかの動きは10月20日の記事にあります。

取り込まれた内容

マージコミットの本文によれば、i82975x、x38、xgene、i3200 の EDAC ドライバが、MAINTAINERS で Orphan（メンテナ不在）になりました。ドライバのソースは、削除されずに残っています。本文は、これらのドライバには通りすがりの更新（drive-by updates）しか届かず、実際に使っている形跡はメーリングリストにない、と書いています。

理由の核心は、次の一文です。“So, with the advent of AI-generated fixes frenzy, and because no one can really test fixes on those, it is time to sunset them …” 実機で試せないドライバに AI が生成した修正が集まる状況を挙げ、引退させる時期だとしています。削除の時期や予定は、一次では確認できません。

対象のうち3つは2000年代半ばの Intel チップセットのドライバで、X-Gene は Applied Micro（APM）の Arm SoC 向けです。

7.3 の開発サイクルでは、ThunderX と MPC85XX の EDAC ドライバが、先に Orphan になっています。理由は AI ではなく、pull request の本文にある、ハードウェアにアクセスできないことです。

同じマージで、新しい EDAC ドライバも2つ入りました。1つは Intel のハードウェアで bitfix filter をリセットする intel-bff です。bitfix filter は、シリコンの経年劣化などで固着したビットを追跡する仕組みです。長く稼働すると一時的なエラーが溜まって詰まることがあるため、あふれたときにリセットします。もう1つは、ハードウェアがなくても EDAC のコアを VM 上で試せるダミードライバです。

7.1 の削除との関係

7.1 では、ISDN、AX.25（アマチュア無線）、ATM、CAIF などが削除されました。net-deletions のマージは Jakub Kicinski 氏の pull request で、削除は138,161行です。本文は、syzbot が古いコードのバグを見つけ、新しい開発者が直そうとする状況を挙げ、“the LLM-pocalypse” を乗り越えるには専任のオーナーが必要で、いなければ削除する、と書いています。Andrew Lunn 氏の ISA と PCMCIA の Ethernet ドライバの削除シリーズのカバーレターは、AI を使う新人と fuzzer が問題を見つけ、メンテナの仕事が増えている、と書いています。経緯は10月12日の記事にあります。

The Register の2026年8月10日付の記事によれば、Linus 氏は 7.2 の rc6 の大きさについて、修正の多くは AI ツールによるレビューから来ていると述べ、これを “the new normal” と呼びました。

自分の環境の確認

動画の訂正です。

動画では、7.1 の約13万8000行の削除を提案したのは Andrew Lunn 氏だと紹介しましたが、net-deletions の pull request は Jakub Kicinski 氏のもので、ISDN、AX.25、ATM、CAIF の削除コミットの作者も Kicinski 氏です。Lunn 氏は、同じマージに含まれる ISA と PCMCIA の Ethernet ドライバ12件の削除（約1万6000行）を提案しました。

5. Siemens Software Center の CVE-2026-110936 と、偽カスタム GPT「Plus 5.6」の ClickFix

2つの話があります。1つは Siemens Software Center の脆弱性 CVE-2026-110936 が悪用されていること、もう1つは ChatGPT のカスタム GPT を入口にした ClickFix の攻撃が見つかったことです。2つが同じ攻撃者の一続きの連鎖だと、確認できた一次情報には書かれていません。以下は、別々の事実として整理します。

Siemens Software Center の脆弱性

Siemens のアドバイザリ SSA-580366 によれば、Software Center は DLL を制御されていない検索パスから読み込みます。認証されたローカルの攻撃者が細工した DLL を置けば、アプリの権限で任意のコードを実行できます。分類は CWE-427 です。

CVSS v4.0 は 8.4 で、ベクトルは AV:L、PR:H です。ローカルで、高い権限が前提です
CVSS v3.1 は 6.7（Medium）です
どちらも Siemens が付けた値で、NVD 自身の評価は、確認時点で “Undergoing Analysis” でした
対象は V4.0.9.8 未満のすべての版で、V4.0.9.8 以降に更新します

アドバイザリの改訂履歴は、V1.0（10月15日、公開）、V1.1（10月17日、Siemens Software Center の対策を追加）、V1.2（10月19日、悪用に関するブログ記事への参照を追加）です。Siemens ProductCERT の10月19日のブログは、攻撃者が、有効な署名のある正規の Software Center を使い、その隣に自分のファイルを置いたと説明し、悪意あるファイルとして AllMyBasic.msi と archive.dll を挙げています。カナダのサイバーセキュリティセンターは、10月19日にAV26-1063で注意喚起を出しました。CISA の KEV には、10月20日に追加されています。

Huntress が報告した偽カスタム GPT

Huntress の記事（9月28日公開）によれば、攻撃者は「Plus 5.6」という名前の偽のカスタム GPT を作り、Google Sites のページへ誘導しました。ページは Cloudflare の CAPTCHA 風の画面で、ClickFix の手口により、PowerShell で悪意ある MSI をダウンロードさせます。Huntress は、この Google Sites のドメインに由来する少なくとも40件のインシデントに対応し、そのうち2件がカスタム GPT 経由だと確認しました。

Huntress が OpenAI に連絡し、最初の偽 GPT は9月25日までに削除されました。9月27日に、Huntress が同じキャンペーンに結び付く新しいカスタム GPT を見つけています。Huntress の記事にある連鎖は、Canon の署名付きアプリ（COTFileReadApp.exe）や Stardock の DeElevate64.exe を使った DLL サイドローディングで、ローダーは NuGet パッケージや WAV ファイルに中身を隠していました。記事に Siemens や AllMyBasic.msi の語はありません。

CrowdStrike は、ブログで2026年版 Global Threat Report を引用し、偽 CAPTCHA を使った事案が2025年に563%増えたと書いています。

Forescout が報告した ROMULUS

Forescout の記事（10月15日公開）は、ROMULUS という複数のペイロードを配る ClickFix の配信基盤を分析しています。同じ認証画面を出す6つの IP アドレスを特定し、LegionLoader の配布や、約881.7MBに水増しされた実行ファイルを報告しています。Help Net Security は、ROMULUS のサーバーの1つが、Siemens が AllMyBasic.msi の配布経路として挙げた IP アドレスと同じだと伝えています。ただし、Plus 5.6 経由の感染が Siemens Software Center を使うものだったとは、どの一次情報にも書かれていません。

読者がすること

Siemens Software Center は V4.0.9.8 以降に更新し、公式の Siemens の配布元だけから入手する
見覚えのない MSI や DLL がないか、Siemens ProductCERT のブログにある検知の目安と照らして確認する
ブラウザの画面から、PowerShell などのコマンドを実行するよう求められたら、実行せずに止める

動画の訂正です。

動画では、Huntress によると「40件を超える」インシデントが「1つの Google Sites のページ」につながっていたと紹介しましたが、Huntress の記事は「少なくとも40件」で、起点は特定の Google Sites のドメインです。この40件と Siemens の連鎖が同じだとも書かれていません（Huntress）。
動画では、OpenAI が9月25日に最初の偽 GPT を削除し、攻撃者が2日後に代わりの GPT を動かし始めたと紹介しましたが、Huntress の記事は、Huntress が OpenAI に連絡して9月25日までに削除されたこと、9月27日に Huntress が新しいカスタム GPT を見つけたことを書いています。攻撃者が稼働を始めた日とは書かれていません。

まとめ

CVE-2026-0257 は、5月の修正が適用されない環境で、10月も狙われています。Linus 氏が AI を使って書いたパッチは、Shutsemau 氏の手で18本の RFC になり、取り込みの前に未解決の点が整理されました。Linux-libre は、リリースのたびに新しい blob 名を掃除します。EDAC の4ドライバは、実機で試せないまま AI 生成の修正が届く状況を理由に、メンテナ不在になりました。Siemens Software Center の脆弱性は、署名のある正規のソフトの隣に DLL を置く形で悪用されています。この共通点は書き手の考察です。

確かめることを挙げます。

PAN-OS の GlobalProtect を使っているなら、版を修正版と照らし、認証オーバーライドクッキーの証明書を使い回していないか確認する
ページキャッシュの RFC は、取り込まれたものと読まず、議論の経過を見る
Linux-libre を使うなら、ディストリビューションの案内で、追従する版を確認する
ECC メモリのサーバーや Arm SoC の古い機器を使っているなら、lsmod で EDAC ドライバの有無を確かめる
Siemens Software Center を入れているなら、V4.0.9.8 以降に更新する

参考リンク

（2026/10/21 Linux・OSSトレンド）

Linux 7.4 に向けた「Y」の付箋と TDX のタイムアウト、ARM64 BE の撤去、Moose 0.6、BeamFS の RFC（2026/10/20 Linux・OSSトレンド）

Tue, 20 Oct 2026 00:00:00 +0900

はじめに

全部は直せないので、印を付け、線を引き、時間を区切る。今回の5本は、どれも直す前に扱い方を決めた話です。カーネルは bind/unbind を使った後のバグ報告に Y の付箋を貼り、Moose は外へ出すデータの範囲に線を引き、TDX では待たされる時間に区切りを付けます。

5本に共通点を見るのは、あくまで書き手の考察です。Linux 7.3 は10月18日（米国時間）に正式リリースされ、7.4 のマージウィンドウが開いたところです。経緯は10月19日の記事にあります。トピック1・3・5は、いずれも 7.4 に向けて送られた段階で、10月19日（UTC）の時点では torvalds/linux に入っていません。動画で一次情報と食い違った発言は、各節末の「動画の訂正」にまとめました。

1. Linux 7.4 の taint フラグ TAINT_FORCED_BIND — 文字は Y、ビット20

Greg Kroah-Hartman 氏が、新しい taint フラグ TAINT_FORCED_BIND を提案しました。最終版 v4 のカバーレターによれば、フラグの文字は、それまで使われていなかった “Y” です。パッチ本体では、tainted-kernels.rst の表に20番として “device was manually bound or unbound from a driver” が加わり、TAINT_FLAGS_COUNT が21になります。

7.4 への取り込み状況

Danilo Krummrich 氏が10月17日付で送った、driver core の7.4 向け pull requestに、このフラグを追加するコミットが含まれています。本文に “All commits have been in linux-next (no conflicts expected)” とあります。10月19日（UTC）の時点では、torvalds/linux の master の先頭は Linux 7.3 のままで、TAINT_FORCED_BIND は入っていません。7.4 で取り込まれる見込みです。

なぜ必要になったか

sysfs の bind と unbind のファイルは、カーネルを作り直さずに開発を回すための、昔からのデバッグ用の入口です。カバーレターによれば、この入口が syzbot のようなツールによる大規模なファジング “attack” にさらされ、どんなドライバでも、どんな種類のデバイスにでも無作為に結び付けようとする使い方をされました。その結果、“loads of unneeded errors and pointless kernel patches to be generated by unsuspecting new developers” が生まれたと書かれています。

syzbot は、syzkaller の文書によれば、見つけたバグをカーネルのメーリングリストへ自動で報告します。bind/unbind には正当な使い道もあり、Phoronix はハードウェアのリセットや “passing devices to a VM” を挙げています。

付箋の貼り方

カバーレターが挙げる狙いは、バグ報告のうち、見る価値のあるものを開発者が見分けやすくなることです。bind/unbind を使う正当な操作も、動作はそのまま続き、カーネルに印が付くだけです。taint は、動いているカーネルが標準と違う状態にあるという記録で、パニックではありません。

印を付ける位置には理由があります。カバーレターは、印が bind/unbind のコールバックの前に付くと明記しています。コールバックの中ではクラッシュや警告がよく起きるので、印が先にないと、何を試みていたかが oops のレポートに残らないためです。実装を見ると、印は対象のデバイスが見つかり、結合の条件を満たした直後の、コールバックの前で付きます。

カバーレターは、syzbot のようなツールは panic_on_taint を有効にして走らせるべきだとも書いています。panic_on_taint は、止めたい taint フラグを16進のビットマスクで指定する起動パラメータなので、Y という文字そのものは渡せません。bind/unbind のファイルを作らない設定（suppress_bind_attrs）のドライバは、そもそも書き込む先がないため、この印の対象になりません。

Y という文字について、カバーレターは、使われていなかった文字で、操作対象のデバイスを力任せに放り投げる “yeeting” として覚えられる、と説明しています。

動画の訂正です。

動画では「パッチはv3まで改訂が重ねられています」と紹介しましたが、7.4 向けの pull request に載ったのは最終版の v4 です（v1 から v4 まで4版。v4 は3パッチ構成）。根拠はv4 のスレッドで、pull request に載ったコミット3本とも一致します。
動画では Y を「yeetingから取った」と紹介しましたが、v4 のカバーレターの原文は、未使用だった文字 Y を yeeting と覚えられる、という覚え方の説明です。由来と言い切るのは言い過ぎでした。

2. GNOME 向け AI チャット Moose 0.6 — クラウドに接続できるようになった

Moose は、GTK4 と libadwaita で作られた GNOME 向けの AI チャットアプリです。READMEによれば、ローカルの AI モデル、または必要に応じてクラウドのプロバイダーと、ネイティブのアプリで会話できます。Rust 製で、ライセンスは GPL-3.0-or-later、Flathub で配布され、対応するアーキテクチャは aarch64 と x86_64 です。

0.6.0 と 0.6.1

0.6.0 のリリースは、GitHub 上の公開日時が10月7日（UTC）で、リリースノートは自分の API キーを使うクラウド接続を加えたと書いています。0.6.1 は10月17日（UTC）に公開され、Mistral AI と DeepSeek が加わりました。日本時間では、それぞれ10月8日と10月17日です。

キーの保管とプライバシー

0.6.0 のリリースノートは、クラウドの認証情報を保護して保存すると説明しています。AppStream の説明では “your desktop’s secret storage” です。実装は、Rust の oo7 クレートでデスクトップのキーリングを使うものです。

ローカル専用（Local Only）モードは、README によれば、リモートでの推論をブロックします。0.6.0 のリリースノートの言い方では、Moose が管理する Ollama だけを使う設定です。リモートのチャットでは、メッセージやファイルを共有する前に許可を求められます。メッセージとファイルの許可は別々で、リリースノートによれば、1つのチャットだけにも、同じプロバイダーのチャット全体にも設定でき、プライバシー設定からリセットできます。

外部の Ollama と保存まわり

外部の Ollama への接続は、0.6.0 から HTTPS が必須になりました。同じ端末の中の接続だけは HTTP も使えます。新しい Files 画面では、添付ファイルとライブラリの文書を閲覧、検索、絞り込みでき、プレビューや、関連するチャットを開き直すこともできます。リリースノートによれば、会話、下書き、文書ライブラリは端末内に保存されます。

README によれば、Flatpak 版はセットアップ手順に沿って Ollama を導入し、モデルのダウンロードまで進められます。

動画の訂正です。

動画では、API キーは「libsecret を通じて」GNOME のキーリングに保存されると紹介しましたが、公式の記述は “desktop keyring” で、libsecret の語はありません。実装は oo7 クレートです（README、資格情報のソース）。
動画では、会話の履歴を SQLite に保存して「全文検索もできる」と紹介しましたが、FTS5 の全文検索の対象は添付とライブラリの文書です。会話履歴の検索は部分一致です（マイグレーション）。

3. Linux 7.4 の ARM64 ビッグエンディアン対応の削除 — BROKEN の印から約1年

64ビット ARM のビッグエンディアン（BE）カーネルのサポートを削除するパッチが、7.4 に向けて送られています。

7.4 への取り込み状況

Catalin Marinas 氏が2026年9月23日に、arm64 ツリーの for-next/be-gone へ適用したと通知しました。適用されたのは v3 です。10月16日には、arm64 の 7.4 向け pull request が送られ、本文に “the removal of big-endian kernel support (already marked BROKEN for some time)” とあります。10月19日（UTC）の時点で torvalds/linux の master には入っておらず、7.4 で取り込まれる見込みです。

BROKEN から削除まで

CPU_BIG_ENDIAN を BROKEN に依存させるコミットは、MAINTAINERS の ARM64 PORT に Catalin Marinas 氏とともに載る Will Deacon 氏が書いたもので、本文に “as an initial deprecation step towards its removal” とあります。同じ本文は、BE の arm64 構成は “vanishingly rare” だと述べます。このコミットは 6.18 の開発サイクルで入り、6.18 の正式リリースは2025年11月30日でした。pull request まで約1年です。BROKEN の項目は、通常の設定メニューからは選べません。

Eric Biggers 氏はレビューの返信で、“It’s already been BROKEN (and thus is dead code) since v6.18.” と書き、さらに “Other code never actually worked correctly on big endian in the first place and no one ever cared.” と続けています。

規模と影響

v2 のカバーレターは14本のパッチで、diffstat は “41 files changed, 54 insertions(+), 539 deletions(-)” です。7.4 向けに送られた v3 は、Will Deacon 氏の13本に Catalin Marinas 氏が gve の Kconfig 依存を足した1本を加えた14コミットで、v3 のカバーレターの diffstat は “42 files changed, 53 insertions(+), 489 deletions(-)” です。

消えるものは、AES や GHASH の暗号アセンブリ、文字列処理の最適化ルーチン、-mbig-endian を指示するコンパイラのフラグなどです。KVM では、BE のハイパーバイザー側オブジェクトの生成と、nVHE の BE 用スピンロック定義が消えます。

7.3 以前のカーネルには影響しません。32ビット ARM の BE は今回の対象外で、Will Deacon 氏は v1 のスレッドで、arm32 側はもう1つ LTS を待つのがよいという考えを示しています。v1 と v3 のスレッドを見た範囲では、反対意見は見当たりませんでした。

動画の訂正です。

動画では「41ファイル、541行削除、54行追加」と紹介しましたが、v2 の diffstat では539行削除です。7.4 向けに送られたのは v3 で、v3 のカバーレターでは489行削除です。
動画では、KVM から消えるものを「ビッグエンディアンのゲスト向けコード」と紹介しましたが、正しくは、BE のハイパーバイザー側オブジェクト（ELF 再配置の生成）と、nVHE の BE 用スピンロック定義です（該当パッチ）。

4. BeamFS の RFC — 壊れた読み出しを返さないファイルシステム

BeamFS は、10月19日（Phoronix の記事日付）に、Linux カーネルのメーリングリストへ RFC として投稿された新しいファイルシステムです。Phoronix の記事は、カバーレターから次の文を引用しています。“beamfs is a block-device filesystem that corrects corrupted bytes in place, on a single device, with no second copy to repair from.”

誤り訂正の仕組み

カバーレターの引用によれば、各データブロックは lib/reed_solomon を土台にした、16本のインターリーブされた RS(255,239) の符号語で構成されます。ディレクトリブロック、inode、アロケーションビットマップ、スーパーブロックにも Reed-Solomon のパリティが付き、間接ブロックには専用のパリティ領域があります。

同じ引用によれば、既定のレイアウトでは4096バイトのうち288バイト（7%）がオーバーヘッドです。リポジトリの文書 capsule.mdによれば、このうちパリティは16バイト×16本の256バイトで、残りは検査値、自己識別、世代番号、予約領域です。

訂正できない読み出しは、間違ったバイト列を返さず -EIO で失敗します。Phoronix によれば、想定するのは、データを1台のストレージに置き、放射線を受けやすい環境で動くシステムです。同じく Phoronix によれば、前身の FTRFS は、人工衛星の搭載コンピューターや放射線治療室を念頭に置いて始まりました。

小ささという方針

開発者のリポジトリのKconfigには、DO-178C、ECSS-E-ST-40C、IEC 61508 の認証を設計上の制約とし、監査できるコードを5000行未満にする、と書かれています。脅威モデルの文書では、比較として ext4 を約10万行と見積もっています。これらは開発者自身の文書の記述で、RFC のカバーレターに載っているかは確認できていません。

FTRFS からの作り直し

前身の FTRFS は、2026年4月13日付の RFCでした。カバーレターの引用によれば、FTRFS の限界は設計（脅威モデル、訂正を置く場所、規模、カーネルとの統合）にあったため、BeamFS は独自のディスク上の形式を持つ新しいファイルシステムとして、新しいスレッドで投稿されています。

現在の版と既知の問題

READMEは、0.1.26 とその後の main に、データを失う、セキュリティを弱める、カーネルをクラッシュさせる既知の欠陥があると警告しています。10月9日のコードレビューで見つかったもので、それ以前のすべての版にもあるとしています。例として次のものがあります。

スパースファイルで、ページ先頭のブロックが穴のとき、読み出しがページ全体をゼロで返し、後の部分書き込みでそのゼロが保存されます。隣のブロックのデータが失われます
初期化されていないカーネルメモリの16バイトが、既定のレイアウトで各データブロックに書き込まれます
書き込みで set-user-ID と set-group-ID のビットが消えません

README は、失ってはいけないデータを置かないこと、自分で作っていないイメージをマウントしないこと、信頼できないユーザーが書き込めるシステムでマウントしないことを求めています。

動画の訂正です。

動画では「約288バイトが訂正用のパリティに使われる」と紹介しましたが、288バイト（約7%）はオーバーヘッド全体で、パリティはそのうち256バイトです（capsule.md）。
動画では、スパースファイルの不具合を「ページをまたいで書き込むと隣のブロックを壊す」と紹介しましたが、README の説明は、穴のブロックがゼロとして読まれ、そのゼロが後の書き込みで保存される、というものです。隣のデータが失われる結果は合っています。

5. Linux 7.4 の KVM/TDX — Instruction Timeout と Bus Lock VM Exit

TDX（Trust Domain Extensions）は、カーネルの文書によれば、ゲストのレジスタの状態を隔離し、メモリを暗号化して、機密ゲスト VM をホストと物理攻撃から守る仕組みです。今回の変更は、KVM が TDX ゲストに対して Instruction Timeout と Bus Lock VM Exit の2つを有効にできるようにするものです。なお、systemd-vmspawn の TDX 対応は9月3日の記事で扱いました。

7.4 への取り込み状況

シリーズは v4（9パッチ）で、Sean Christopherson 氏が kvm-x86 の vmx ブランチに適用しています。7.4 向けの pull request（Paolo Bonzini 氏宛て、10月16日）の件名は “KVM: x86: VMX+TDX changes for 7.4” で、同氏は受け取りを “Pulled all, thanks (for now to kvm/queue).” と返しています。Linus 宛ての pull request は確認できておらず、torvalds/linux の master にも入っていません。7.4 で取り込まれる見込みです。

Instruction Timeout

Instruction Timeout は、KVM では Notify VM Exit と呼ばれてきた機能です。pull request の文面は “now called Instruction Timeout in the SDM” と書きます。KVM の API 文書によれば、イベントウィンドウが開かないまま、指定した時間（notify window）が経過すると VM Exit します。目的は、悪意のある VM が CPU を固まらせ、ホストや他の VM が使えなくなる事態の緩和です。この機能は2022年にコミットされたもので、通常の VM 向けには前からありました。v4 のパッチによれば、IRET の実行中に起こることもあり、IRET が NMI のブロックを解除する場合は exit qualification のビット12が立ちます。

Bus Lock VM Exit

Bus Lock VM Exit は、v1 のカバーレターによれば、バスロックを発生させる命令の実行後に VM Exit します。“This VM exit is trap-like, meaning it does not prevent the bus lock from occurring but can detect that one has occurred.” という仕組みで、バスロックを止めるのではなく、起きたことを検出して通知します。通知先は QEMU などのユーザー空間です。

TDX でだけ有効になっていなかった

適用済みのコミットの説明によれば、ユーザー空間は TDX ゲストにこの機能を有効にしてもエラーを受け取りませんが、KVM が TDX モジュールの API を呼んで TD VMCS の対応する項目を設定しないため、実際には有効になっていませんでした。pull request の言い方は “KVM forgot to wire up the TDX Module knobs” です。Bus Lock 側は別のコミットで、TD VMCS の BUS_LOCK_DETECTION の設定と VM Exit のハンドラを加えます。

投稿者は Intel の Xiaoyao Li 氏で、v1（8月5日）から v4（8月19日）までの4版です。v4 のカバーレターによれば、最初の8パッチは stable カーネル向けです。そのため、ディストリビューションのカーネル更新でも届く見込みがあります。有効にするのはホスト側の VMM です。QEMU は Notify VM Exit を既定で有効にしますが、Bus Lock は bus-lock-ratelimit に0より大きい値を指定したときだけ有効になります。

動画の訂正です。

動画では、Instruction Timeout を「IRETという命令などの実行が一定の回数を超えると、CPUが強制的にゲストから制御を取り上げて、ホストに返す」と紹介し、一定回数で強制退場させる例えも添えましたが、回数ではなく時間の仕組みです。イベントウィンドウが開かないまま一定の時間が経過すると VM Exit します（api.rst の “a VM exit if no event window occurs in VM non-root mode for a specified of time (notify window)"、コミット 2f4073e08f4c）。動画タイトルの「時間を区切る」のほうが実態に合っています。
動画の終盤で「悪さを続けられる回数には上限を決めておく」「居座れる回数に上限を付けました」と紹介しましたが、Instruction Timeout は時間の上限です。Bus Lock VM Exit に上限はなく、バスロックの発生後に検出して通知する仕組みです（v1 のカバーレターの “does not prevent the bus lock from occurring but can detect that one has occurred”）。

まとめ

Y の付箋は、直さない代わりに見分けるための印でした。Moose は、クラウドへ送る範囲を自分で決められる作りです。ARM64 BE は、BROKEN を付けてから約1年で撤去に向かい、BeamFS は直せない破損を -EIO で知らせます。TDX は、中を見ない代わりに、固まる時間に区切りを付けます。この共通点は書き手の考察です。

確かめることを挙げます。

カーネルのバグ報告を読むなら、7.4 に取り込まれた後は taint の表示に Y があるかを確かめる。Y があれば、bind/unbind の操作があった報告です
Moose を試すなら、クラウドを使う前にプライバシー設定の共有範囲と、Local Only の設定を確かめる
ARM64 で BE カーネルを使っているなら、7.4 以降では BE のカーネルを作れなくなる見込みなので、7.3 以前に留まるか、移行を考える
BeamFS を試すなら、README の警告どおり、失ってもよいデータとイメージだけで試す
TDX のホストを運用する場合は、KVM と QEMU の更新で、Bus Lock の設定も含めて確かめる

参考リンク

（2026/10/20 Linux・OSSトレンド）