<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Linuxカーネル on 思いつきそうで思いつかなくていたときに</title><link>https://blog.fuga.jp/tags/linux%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB/</link><description>Recent content in Linuxカーネル on 思いつきそうで思いつかなくていたときに</description><generator>Hugo -- gohugo.io</generator><language>ja-jp</language><copyright>Copyright(c) 2022-2025 SATO Daisuke. All rights reserved.</copyright><lastBuildDate>Tue, 21 Jul 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://blog.fuga.jp/tags/linux%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB/index.xml" rel="self" type="application/rss+xml"/><item><title>15年潜んだnginxの欠陥に$10の値札——変わらないものに手術が入った日</title><link>https://blog.fuga.jp/posts/2026-07-21-linux-oss-trend/</link><pubDate>Tue, 21 Jul 2026 00:00:00 +0900</pubDate><guid>https://blog.fuga.jp/posts/2026-07-21-linux-oss-trend/</guid><description>&lt;h2 id="はじめに"&gt;&lt;a href="#%e3%81%af%e3%81%98%e3%82%81%e3%81%ab" class="header-anchor"&gt;&lt;/a&gt;はじめに
&lt;/h2&gt;&lt;p&gt;15年動き続けてきたnginxのコードに &lt;strong&gt;CVSS9.2&lt;/strong&gt; の欠陥が見つかり、長年使われてきたDNSリゾルバが載せ替えられ、無料で試せていたGitHubの機能に$10の値札がついた——今日はそんな一日だった。「長く変わらなかったもの」に、同じ日にまとめて手が入ったニュースを5本紹介する。&lt;/p&gt;
&lt;div class="video-wrapper"&gt;
 &lt;iframe loading="lazy" 
 src="https://www.youtube.com/embed/d75tYXqVRTk" 
 allowfullscreen 
 title="YouTube Video"
 &gt;
 &lt;/iframe&gt;
&lt;/div&gt;

&lt;h2 id="1-cve-2026-42533nginx全世代を貫くヒープ破壊cvss92"&gt;&lt;a href="#1-cve-2026-42533nginx%e5%85%a8%e4%b8%96%e4%bb%a3%e3%82%92%e8%b2%ab%e3%81%8f%e3%83%92%e3%83%bc%e3%83%97%e7%a0%b4%e5%a3%8acvss92" class="header-anchor"&gt;&lt;/a&gt;1. CVE-2026-42533——nginx全世代を貫くヒープ破壊、CVSS9.2
&lt;/h2&gt;&lt;p&gt;まずは今日いちばん手を止めてほしい話から。ウェブサーバーnginxに、2011年3月から実に15年ものあいだ潜んでいたヒープバッファオーバーフロー &lt;strong&gt;&lt;a class="link" href="https://www.cve.org/CVERecord?id=CVE-2026-42533" target="_blank" rel="noopener"
 &gt;CVE-2026-42533&lt;/a&gt;&lt;/strong&gt; が公開された。深刻度は&lt;a class="link" href="https://nvd.nist.gov/vuln/detail/CVE-2026-42533" target="_blank" rel="noopener"
 &gt;NVDの掲載&lt;/a&gt;によればCVSS4.0で &lt;strong&gt;9.2(CRITICAL)&lt;/strong&gt; 、CVSS3.1でも8.1(HIGH)と両バージョンのスコアが併記されている。原因は&lt;a class="link" href="https://nginx.org/en/security_advisories.html" target="_blank" rel="noopener"
 &gt;nginxのセキュリティアドバイザリ&lt;/a&gt;によれば、&lt;code&gt;map&lt;/code&gt; ディレクティブで正規表現のキャプチャグループを使う設定で、変数展開の「2パス方式」における状態の保存・復元漏れだ。第1パスで計測した長さと第2パスの書き込みがズレ、ヒープを踏み越えたり、逆に未初期化領域がそのまま漏れたりする。&lt;/p&gt;
&lt;p&gt;正直に言うと、この記事を書きながら自分が管理してる検証サーバーで &lt;code&gt;nginx -v&lt;/code&gt; を叩いてみたら、案の定バージョンを2年近く上げていなかった。人のことを言えた義理ではない。研究者Stan Shawは、&lt;a class="link" href="https://thecyberexpress.com/cve-2026-42533-pre-auth-nginx-rce/" target="_blank" rel="noopener"
 &gt;The Cyber Expressの報道&lt;/a&gt;によれば、Ubuntu 24.04のデフォルト構成で通常のGETリクエスト1本からヒープ上のアドレスを回収できることを実証し、ASLR有効環境でも &lt;strong&gt;10回中10回のRCE成功&lt;/strong&gt; を報告している。この数字にはさすがにぞっとした。認証は不要だ。ベンダーのF5は&lt;a class="link" href="https://my.f5.com/manage/s/article/K000162097" target="_blank" rel="noopener"
 &gt;公式アドバイザリ&lt;/a&gt;で「ASLRが無効または回避可能な環境でのRCE」と条件付きで表現しているが、Stan Shaw側は「この脆弱性自体がASLRバイパスを供給する仕組みだから実際の危険度はもっと高い」と反論しており、ここは両論併記しておきたい。&lt;/p&gt;
&lt;p&gt;対象はNGINX Open Source 0.9.6〜1.31.2、NGINX Plus R33〜37.0.2.1と広範囲。修正版は&lt;a class="link" href="https://nginx.org/en/CHANGES" target="_blank" rel="noopener"
 &gt;nginxの変更履歴&lt;/a&gt;によれば1.30.4/1.31.3、NGINX Plusは37.0.3.1だ。PoCは2026年8月5日ごろ公開予定とされ、まだ出ていない。自分の &lt;code&gt;map&lt;/code&gt; 設定に当該パターンがないか、今すぐ確認しておきたい(そして自分も今日中にアップデートする)。&lt;/p&gt;
&lt;h2 id="2-firefox-153linuxnvidiaの宿願vulkan-videoデコードが公式対応"&gt;&lt;a href="#2-firefox-153linuxnvidia%e3%81%ae%e5%ae%bf%e9%a1%98vulkan-video%e3%83%87%e3%82%b3%e3%83%bc%e3%83%89%e3%81%8c%e5%85%ac%e5%bc%8f%e5%af%be%e5%bf%9c" class="header-anchor"&gt;&lt;/a&gt;2. Firefox 153——Linux×NVIDIAの宿願、Vulkan Videoデコードが公式対応
&lt;/h2&gt;&lt;p&gt;強い緊張の話のあとは少し前向きなニュースへ。2026年7月21日リリースのFirefox 153が、Linux上のNVIDIA GPU向け &lt;strong&gt;&lt;a class="link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=2021722" target="_blank" rel="noopener"
 &gt;Vulkan Videoデコード&lt;/a&gt;&lt;/strong&gt; を初めて実装した。長年FirefoxはLinux上のNVIDIA環境でハードウェアビデオデコードを無効化しており、動画再生はCPU任せでファンが回りっぱなしという状況が続いていた。Linuxユーザーなら「またNVIDIAだけ後回しか」とぼやいた経験、一度はあるはずだ。それがようやく公式の解を得た。&lt;/p&gt;
&lt;p&gt;実装の中身は、&lt;a class="link" href="https://bugzilla.mozilla.org/show_bug.cgi?id=2021722" target="_blank" rel="noopener"
 &gt;Mozillaのバグトラッカー&lt;/a&gt;によれば、FFmpeg 6.1.1以降が備えるVulkan Videoデコードパスを、Firefoxの&lt;code&gt;FFmpegVideoDecoder&lt;/code&gt;から呼び出すというもの。主要実装者は&lt;a class="link" href="https://www.omgubuntu.co.uk/2026/07/firefox-vulkan-video-decoding-nvidia" target="_blank" rel="noopener"
 &gt;NVIDIAのエンジニアTymur Boiko&lt;/a&gt;で、レビューはRed HatのエンジニアMartin Stránskýが担当しており、GPUベンダー自身がブラウザ本体にパッチを送るクロスベンダー協力の一例になっている。現時点では既定オフで、&lt;a class="link" href="https://www.omgubuntu.co.uk/2026/07/firefox-vulkan-video-decoding-nvidia" target="_blank" rel="noopener"
 &gt;NVIDIAドライバー595.x以降&lt;/a&gt;と&lt;code&gt;about:config&lt;/code&gt;での2フラグ(&lt;code&gt;media.hardware-video-decoding-vulkan.enabled&lt;/code&gt; / &lt;code&gt;media.hardware-video-decoding-vulkan.direct-export.enabled&lt;/code&gt;)有効化が必要だ(余談だが筆者の手元機材はIntel内蔵GPUなので、これは残念ながら試せない)。&lt;/p&gt;
&lt;p&gt;正直に書いておくと、&lt;a class="link" href="https://www.omgubuntu.co.uk/2026/07/firefox-vulkan-video-decoding-nvidia" target="_blank" rel="noopener"
 &gt;OMG! Ubuntuの報道&lt;/a&gt;ではデュアルGPU構成のノートPCでワークスペース切り替え時にスタッターが出る報告もあり、既定オフなのはそうした未成熟さもあってのことだ。手放しで全員に勧める段階ではないが、&lt;code&gt;nvidia-vaapi-driver&lt;/code&gt;という壊れやすいワークアラウンドへの依存が要らなくなる意義は大きい。&lt;/p&gt;
&lt;h2 id="3-ipfire-229-core-update-203dnsの心臓をunboundからknot-resolverへ"&gt;&lt;a href="#3-ipfire-229-core-update-203dns%e3%81%ae%e5%bf%83%e8%87%93%e3%82%92unbound%e3%81%8b%e3%82%89knot-resolver%e3%81%b8" class="header-anchor"&gt;&lt;/a&gt;3. IPFire 2.29 Core Update 203——DNSの心臓をUnboundからKnot Resolverへ
&lt;/h2&gt;&lt;p&gt;ここが今日の谷、いちばん地味な話。ファイアウォール専用ディストリビューションIPFireが、2026年7月20日公開の&lt;a class="link" href="https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released" target="_blank" rel="noopener"
 &gt;Core Update 203&lt;/a&gt;で、DNSリゾルバを長年使ってきたUnboundからKnot Resolverへ全面移行した。&lt;a class="link" href="https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released" target="_blank" rel="noopener"
 &gt;公式ブログ&lt;/a&gt;は「Unboundは長年IPFireによく尽くしてくれた」としつつ、より深く統合できるモジュラーなアーキテクチャを求めてKnot Resolverへの切り替えに踏み切ったと説明している。DNSリゾルバはファイアウォールにとって単なる名前解決の道具ではなく「どこへ繋がせるか」を決める場所でもあり、地味に見えて実は大手術だ。個人的には、こういう地道な土台の入れ替え作業が異常に好きだ。派手さはゼロだが、効いてくるのはたぶんここだと思っている。&lt;/p&gt;
&lt;p&gt;これにより、&lt;a class="link" href="https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released" target="_blank" rel="noopener"
 &gt;公式ブログ&lt;/a&gt;によれば &lt;strong&gt;DNS over TLS上流転送&lt;/strong&gt; 、悪意あるドメインをリゾルバ段階でブロックする &lt;strong&gt;DNSファイアウォール&lt;/strong&gt; 、DHCPホスト名解決、再起動をまたぐ永続キャッシュが新たに使えるようになった。あわせてWi-Fi 6GHz帯サポートも追加されている。&lt;/p&gt;
&lt;p&gt;ここは正直に書いておくと、今回の素材の範囲では移行に伴う設定互換性の細部や、Unbound設定の自動引き継ぎの有無、性能の定量比較といった数値は取得できていない。Core Update適用前にリリースノートを読み、設定のバックアップを取ってから進めるのが安全だろう。&lt;/p&gt;
&lt;h2 id="4-github-code-quality-gaaiコードレビューと品質ゲート10人の有料化"&gt;&lt;a href="#4-github-code-quality-gaai%e3%82%b3%e3%83%bc%e3%83%89%e3%83%ac%e3%83%93%e3%83%a5%e3%83%bc%e3%81%a8%e5%93%81%e8%b3%aa%e3%82%b2%e3%83%bc%e3%83%8810%e4%ba%ba%e3%81%ae%e6%9c%89%e6%96%99%e5%8c%96" class="header-anchor"&gt;&lt;/a&gt;4. GitHub Code Quality GA——AIコードレビューと品質ゲート、$10/人の「有料化」
&lt;/h2&gt;&lt;p&gt;谷を抜けて、身近で議論を呼ぶ話へ。&lt;a class="link" href="https://github.blog/changelog/2026-06-16-github-code-quality-generally-available-july-20-2026/" target="_blank" rel="noopener"
 &gt;GitHub Code Qualityが2026年7月20日に一般提供(GA)へ移行した&lt;/a&gt;。パブリックプレビュー段階で&lt;a class="link" href="https://github.blog/changelog/2026-06-16-github-code-quality-generally-available-july-20-2026/" target="_blank" rel="noopener"
 &gt;1万社超が触ってきた&lt;/a&gt;AIコードレビュー・品質ゲート機能が、正式版になると同時に有料化された。課金は3層構造で、&lt;a class="link" href="https://docs.github.com/en/billing/concepts/product-billing/github-code-quality" target="_blank" rel="noopener"
 &gt;GitHubの課金体系ドキュメント&lt;/a&gt;によれば月額 &lt;strong&gt;$10/アクティブコミッター&lt;/strong&gt; (ライセンス料)＋AI使用量＋GitHub Actions実行時間。対象は&lt;a class="link" href="https://docs.github.com/en/billing/concepts/product-billing/github-code-quality" target="_blank" rel="noopener"
 &gt;GitHub Enterprise CloudとGitHub Team&lt;/a&gt;で、オンプレミスのGitHub Enterprise Serverは対象外だ。&lt;/p&gt;
&lt;p&gt;目玉のCopilot Autofixは、PRのインラインコメントに自動修正提案を差し込む機能で、&lt;a class="link" href="https://github.com/orgs/community/discussions/177488" target="_blank" rel="noopener"
 &gt;GitHub Community Discussionsのユーザー投稿&lt;/a&gt;には「単純な問題(未使用importやnullチェックなど)の約70%で良好に機能する」という声もある。他の静的解析SaaSでは、たとえば競合のSonarCloudが小規模プライベートチーム向けに月$75〜150程度と&lt;a class="link" href="https://byteiota.com/github-code-quality-ga-pricing/" target="_blank" rel="noopener"
 &gt;報じられており&lt;/a&gt;、これを踏まえると100人規模の組織なら基本ライセンスだけで年$12,000という価格感には、コミュニティでも議論が起きている。パブリックプレビュー中に有効化したまま放置している組織は、7月20日以降、追加操作なしで自動的に課金が始まると&lt;a class="link" href="https://byteiota.com/github-code-quality-ga-pricing/" target="_blank" rel="noopener"
 &gt;報じられており&lt;/a&gt;、この点も見落としやすい。&lt;/p&gt;
&lt;p&gt;1万社が無料で試して開発フローに組み込んだところへ$10の値札がついた、というのが今日の話の中でも一番「無料の終わり」を生々しく感じさせる一件だと思う。皆さんの会社なら、この価格感、払う派ですか、それとも様子見派ですか。&lt;/p&gt;
&lt;h2 id="5-linux-72-rc4mongodb最大100高速化とzen-5向けスケジューラ改善strncpyは永久追放"&gt;&lt;a href="#5-linux-72-rc4mongodb%e6%9c%80%e5%a4%a7100%e9%ab%98%e9%80%9f%e5%8c%96%e3%81%a8zen-5%e5%90%91%e3%81%91%e3%82%b9%e3%82%b1%e3%82%b8%e3%83%a5%e3%83%bc%e3%83%a9%e6%94%b9%e5%96%84strncpy%e3%81%af%e6%b0%b8%e4%b9%85%e8%bf%bd%e6%94%be" class="header-anchor"&gt;&lt;/a&gt;5. Linux 7.2-rc4——MongoDB最大100%高速化とZen 5向けスケジューラ改善、strncpyは永久追放
&lt;/h2&gt;&lt;p&gt;締めは、いちばん土台に近くて、いちばん未来につながる話。2026年7月19日に公開された&lt;a class="link" href="https://www.kernel.org/" target="_blank" rel="noopener"
 &gt;Linux 7.2-rc4&lt;/a&gt;では、&lt;a class="link" href="https://www.linuxcompatible.org/story/linux-kernel-72rc4-drops-cacheaware-scheduling-mongodb-speedups-and-the-end-of-strncpy" target="_blank" rel="noopener"
 &gt;MGLRU(Multi-Gen LRU)の改善によりベンチマークでMongoDBのスループットが最大100%&lt;/a&gt;——つまり2倍——向上したと報じられている。あわせて、&lt;a class="link" href="https://www.linuxcompatible.org/story/linux-kernel-72rc4-drops-cacheaware-scheduling-mongodb-speedups-and-the-end-of-strncpy" target="_blank" rel="noopener"
 &gt;キャッシュ認識スケジューリング(Cache-Aware Scheduling)がAMD Zen 5環境でPostgreSQL・Valkey・ネットワークワークロードに意味のある性能向上をもたらした&lt;/a&gt;ほか、Btrfsではlarge foliosがデフォルトで有効化され、AMDGPUではHDMI 2.1のFRL初期サポートが入った。カーネルコードは4,300万行を超えた。&lt;/p&gt;
&lt;p&gt;個人的にいちばん味わい深いのは、C言語の古典的な文字列コピー関数 &lt;code&gt;strncpy&lt;/code&gt; がカーネルソースから完全に姿を消したという一点だ。strncpyはコピー先が切り詰められたときに終端のNULを保証しないなど誤用しやすく、バッファ関連バグの温床として長く知られてきた。カーネル開発者たちは数年がかりでより安全な代替への置き換えを進め、この7.2サイクルでついに1つ残らず消し去った。地味に感動した。これは今日冒頭のnginxの脆弱性とも無関係ではなく、C由来のメモリ安全性の脆さを、片方は事故として抱え、もう片方は予防として断ち切っている、そんな一日だった。&lt;/p&gt;
&lt;h2 id="まとめ"&gt;&lt;a href="#%e3%81%be%e3%81%a8%e3%82%81" class="header-anchor"&gt;&lt;/a&gt;まとめ
&lt;/h2&gt;&lt;p&gt;今日の5本を通して感じたのは、「長く当たり前だったものが、その足元を問われる」一日だったということだ。15年潜んだnginxの欠陥、長年頼ったIPFireのDNSリゾルバ、無料が当たり前だったGitHubの機能——どれも「変わらないこと」の価値とコストが同時に可視化された日だったように思う。皆さんの環境、nginxのバージョンは今すぐ確認できていますか。&lt;/p&gt;
&lt;h2 id="参考リンク"&gt;&lt;a href="#%e5%8f%82%e8%80%83%e3%83%aa%e3%83%b3%e3%82%af" class="header-anchor"&gt;&lt;/a&gt;参考リンク
&lt;/h2&gt;&lt;ul&gt;
&lt;li&gt;nginx公式セキュリティアドバイザリ: &lt;a class="link" href="https://nginx.org/en/security_advisories.html" target="_blank" rel="noopener"
 &gt;https://nginx.org/en/security_advisories.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Firefox 153 公式リリースノート: &lt;a class="link" href="https://www.mozilla.org/en-US/firefox/153.0/releasenotes/" target="_blank" rel="noopener"
 &gt;https://www.mozilla.org/en-US/firefox/153.0/releasenotes/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;IPFire公式ブログ(Core Update 203リリース告知): &lt;a class="link" href="https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released" target="_blank" rel="noopener"
 &gt;https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;GitHub Changelog(GA告知): &lt;a class="link" href="https://github.blog/changelog/2026-06-16-github-code-quality-generally-available-july-20-2026/" target="_blank" rel="noopener"
 &gt;https://github.blog/changelog/2026-06-16-github-code-quality-generally-available-july-20-2026/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;The Linux Kernel Archives: &lt;a class="link" href="https://www.kernel.org/" target="_blank" rel="noopener"
 &gt;https://www.kernel.org/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description></item></channel></rss>