Stonking（Ubuntu 26.10）の開発; ubuntu-lint
stonkingの開発はいわゆる「夏休みシーズン」に差し掛かっていること、そして8月20日のFeature Freezeまでそれなりに時間があること から、大きなイベントは起きていません。
GNOME 51 Alpha の取り込みまでの間は、OpenSSL4マイグレーションのためのさまざまな作業 （主にコンパイル不可能になったパッケージの回復）が行われる「開発版としては落ち着いた」状態となっています。
こうした「ある種」おだやかな空間の中で、新しくubuntu-lint と呼ばれるツールが登場しています。
これは既存の（Debianの）パッケージの静的チェックツールであるlintian とはまた異なるもので、「 in an effort to improve Ubuntu upload quality and developer experience, and help create consistency around existing conventions.」（ Ubuntuのアップロード品質と開発者エクスペリエンスを向上させ、既存の慣習の一貫性を高める）ことを目的に開発されている、という性質のものです。
たとえばdputフックとして、アップロード先がPPAの場合 専用のルーチンを通す、あるいはgit-ubuntuを前提としてgit的なメタデータとパッケージの記載が正しいかを確認する、SRU（Stable Release Updates）に該当する場合はテンプレート文書が存在するかをチェックする といった形で、『 Ubuntuにおけるパッケージング』の文脈を理解した処理が行われるというものです。
“Januscape”（CVE-2026-53359）脆弱性の緩和策
KVMのゲストマシンから仮想化ホストを侵害できる（いわゆる「VMエスケープ」が可能です） 、“ Januscape” （CVE-2026-53359 ）への緩和策についての解説が行われています。
この脆弱性はLinuxカーネルのネスト仮想化における「各種x64 CPUの仮想化アクセラレーションを利用するルーチン」の問題で、ゲストマシンから仮想化ホストのカーネルシャドウページを変更できる 問題です。端的には、「 悪意あるゲストマシンから仮想化ホストのroot権限を取れる（ただし、現状ではきわめて制御された環境でのPoCコードしかない） 」というものです。
意思決定に影響するのは以下の点です。
現状では、DoSが可能なPoCコードが存在します。
現時点で仮想マシンが動作していない場合でも、「 ゲストマシンから仮想化ホストのrootを侵害できる」という特性から、（ ユーザーに仮想化系の権限が付与されている場合）新規に仮想マシンを作成することでローカル権限昇格として悪用できる可能性があります。また、「 もしかすると」/dev/kvmを直接操作することで類似する操作が可能かもしれません。
ネスト仮想化を利用していない環境では、ネスト仮想化に必要になるカーネルモジュール（kvm_amdとkvm_intel）のロードを禁止することで影響を受けない状態にできます。
ネスト仮想化を利用している環境では更新版のカーネルが提供される予定です。
「信頼できない仮想マシン」が実行される環境、つまり不特定多数が利用する仮想化ホスト（いわゆるクラウド環境）においては、提供元の側での対処が必要です。
なおquesting（Ubuntu 25.10）は7月9日にEOL済み なので、修正版カーネルが提供されることはありません。
その他のニュース
“ linux-vmware” 正式なリリースやドキュメントはまだ存在していません。 Claude Codeの「デスクトップLinux向け」ベータ版がリリース されています。「 Ubuntu 22.04 or later, or Debian 12 or later」という形で、専用のaptリポジトリから導入する形になっています。音声入力を含むいくつかの機能はまだ利用できませんが、「 RHELやFedoraは今後サポート」という印象的なリリース形態になっています。
「ML環境を作ったつもりが、2日目には意図せずフルタイムのインフラストラクチャ管理に巻き込まれてしまう」 kubeflow上で動作するタイプのMLワークロードの「あるある」と、Azure上のCanonical Managed Kubeflowがこの問題をどのように解決するのか、を説明する記事。
注目すべきセキュリティー的な視点： カーネルの更新とライブパッチ今回は“ Januscape” のような「カーネルの脆弱性にどのように対応していくか」です。2026年に入ってから、AIによる脆弱性探索支援の影響もあり、体感的には隔週刊に近いペースで「パッチするべきカーネルの脆弱性」が発見されています。
通常、Linuxにおいて「カーネルの脆弱性」に対処するには2つの方法があります。ひとつはカーネルを更新すること、そしてもうひとつが緩和策を適用することです。緩和策というのはたとえば「問題がモジュール単位で存在しており、それらのモジュールが必要のないシステムである」という前提において、該当モジュールをdenylistに入れる」「 eBPFで該当部に迂回処理を作る」といったものがあります。一部の操作に伴ってカーネルモジュールは動的にロードされる可能性があるので、「 ロードされていないが、脆弱性のあるモジュール」をそのままにすることはリスクがあります。
これらに加えて、一部のディストリビューションでは「カーネルライブパッチ」に分類される、メモリ空間にすでにロードされたカーネルをパッチする、というアプローチがあります。Ubuntuにおいては、Livepatchを使うことで「すぐに再起動しなければならない」という制約を緩和できます。
一方、カーネルライブパッチのたぐいには（UbuntuにおけるLivepatch実装だけではなく、すべての実装において）一定の制約があります。
まず、「 再起動が不要になる」のはカーネル起因の脆弱性だけである、という原理的な問題です。glibcの更新のような各種プロセスを再起動すること（そして、「 再起動しなければいけないものがそのまま動いていないこと」を確認すること）はまったく別の話ですし、システムの再起動が必要になるシナリオはカーネルの更新だけではありません。
つまり、仮にすべてのカーネル修正をライブ更新でクリアできたとしても、システムの再起動はなくなりません。たとえばCPUのマイクロコードの更新は「カーネル以外」の再起動を要求する処理の代表例です。マイクロコードの更新はOS起動後は部分的になるため 、なんらかの形でOSを再起動する必要があります（逆に、電源を落とさない限りは一度更新したマイクロコードはそのまま適用されます） 。おおむね四半期ごとにやってくるため、これらの更新のための備えが別途必要です。
そしてカーネルライブパッチのたぐいは、関数単位、あるいは処理の単位で「新しいもの」に「すりかえる」ことで実現されています。システム上、「 新しいコードをメモリ空間上に配置し、ある呼び出しが行われた場合に新しいコードの側を通るようにする」という方式で行われているので、いくら適切な適用が行われたとしても、以前のコードがメモリ空間上に残ることになります。
すべての関数を新しい呼び出しに置き換えたとしても、以前の関数が占めていたメモリ空間はそのまま使用不能な状態で残されます。実装が改善されて仮にメモリ空間を開放できたとしてもこの空間はメモリ配置上は断片化しており、この空間を適切な形でメモリ上に再配置できるわけではありません（そこまでカバーする実装が将来的に出てこないとは言い切れませんが、相当にやっかいな問題が残ります） 。その分、カーネルが占有するメモリ空間は大きくなっていくことになります。また、ライブ更新用のカーネル空間は上限があり、無限に蓄積できるわけではありません。
現状Linuxディストリビューションの多くで、カーネルのライブ更新が実現されていますが、あくまで時間稼ぎという位置づけになっているのは、こうした理由によります。また「すりかえ」を行う上で、「妥当なタイミング」を狙って 遷移状態が継続することも珍しくありません。
アーキテクチャ設計のレベルで「ノード単位で再起動できるようにする」ことのほうが現実的です。
すべての問題をライブ更新に依存することはできません。もちろん何もないことに比べて明らかに状況を改善することはできるものの、できるのは再起動タイミングの短期的な遅延であって、永遠にその環境を維持できるわけではありません（なにしろ「ライブパッチが出る対象カーネル」には限度があるので、そこで再起動が強制されることになります） 。
こうした問題を回避するためには、たとえばエッジサーバーを複数配置しておき、エッジサーバー側は「ある程度気軽に」再起動できるような構造にしておく、といったモデルが考えられます。データベースサーバーであれば複数のサーバーを起動してシャーディングし、故障耐性を兼ねる形で冗長構成を組み、ローリングアップデートできるようにする、そもそも定期的なメンテナンスを挿入できるようにする、といった方法論がありえます。
カーネルの脆弱性が減っていくと考えることは危険な仮定で、おそらく今後も継続して脆弱性が発見され続けることになるでしょう。適切なコアループを設計し、設計を更新しながらシステムを運用するしかありません。こうした問題に対応するには、関係者のリテラシーをいかに高めるか、という問題に対処する必要があります。
こうしたことを検討するには、本当に24h365が必要なのか、あるいはトータルダウンタイムがどれぐらい許容できるのか、といったことを真剣に考える必要があります。こうしたものはユーザーインタビューでは「短ければ短いほどよい」あるいは「ダウンタイムがあるなどとは許されない」といった回答が返ってきてしまうものなので、単純な交渉で打開することも困難です。システム構築の現場でよく見られる「それはいくらかかるんだ」という会話だけでは問題は解決できず、業務とそれを支える補給線であるシステムの相互の理解が必要です。
