linux-4.1.15_CVE-2022-45934

現在のソースツリーのバージョン "X" より大きいすべてのバージョンについて "x" を 順番に 置き換えれば問題ありません。バックアップファイル（some-file-name~ または some-file-name.orig）を削除し、失敗したパッチ（some-file-name# または some-file-name.rej）がないことを確認することをお勧めします。もしあれば、私またはあなたのどちらかに誤りがあります。

4.x カーネル用のパッチとは異なり、4.x.y カーネル（-stable カーネルとしても知られる）用のパッチはインクリメンタルではなく、ベースの 4.x カーネルに直接適用されます。例えば、ベースカーネルが 4.0 で 4.0.3 パッチを適用したい場合、最初に 4.0.1 および 4.0.2 パッチを適用してはいけません。同様に、カーネルバージョン 4.0.2 を実行していて 4.0.3 にジャンプしたい場合、4.0.3 パッチを適用する 前に、最初に 4.0.2 パッチを逆適用（つまり patch -R）する必要があります。詳細については Documentation/applying-patches.txt をお読みください。

あるいは、スクリプト patch-kernel を使用してこのプロセスを自動化することもできます。現在のカーネルバージョンを判別し、見つかったパッチをすべて適用します。

linux/scripts/patch-kernel linux

上記のコマンドの最初の引数はカーネルソースの場所です。パッチはカレントディレクトリから適用されますが、代替ディレクトリを2番目の引数として指定することもできます。

ソフトウェア要件

4.x カーネルのコンパイルと実行には、さまざまなソフトウェアパッケージの最新バージョンが必要です。必要な最小バージョン番号と、これらのパッケージの更新方法については Documentation/Changes を参照してください。これらのパッケージの古すぎるバージョンを使用すると、追跡が非常に困難な間接的なエラーが発生する可能性があるため、ビルド中または動作中に明らかな問題が発生した場合にパッケージを更新するだけで大丈夫だと思い込まないでください。

カーネルの BUILD ディレクトリ：

カーネルをコンパイルするとき、デフォルトではすべての出力ファイルはカーネルソースコードとともに保存されます。 "make O=output/dir" オプションを使用すると、出力ファイル（.config を含む）の代替場所を指定できます。 例：

カーネルを設定およびビルドするには、以下を使用します：

注意：'O=output/dir' オプションを使用する場合は、make のすべての呼び出しで使用する必要があります。

カーネルの設定：

マイナーバージョンを1つアップグレードするだけでも、この手順をスキップしないでください。新しい設定オプションは各リリースで追加され、設定ファイルが期待通りに設定されていないと、奇妙な問題が発生します。最小限の作業で既存の設定を新しいバージョンに引き継ぎたい場合は、"make oldconfig" を使用してください。これは新しい質問に対する回答のみを尋ねます。

• 代替設定コマンドは以下のとおりです：

  "make config" プレーンテキストインターフェース。

  "make menuconfig" テキストベースのカラーメニュー、ラジオリスト、ダイアログ。

  "make nconfig" 拡張テキストベースのカラーメニュー。

  "make xconfig" X windows (Qt) ベースの設定ツール。

  "make gconfig" X windows (Gtk) ベースの設定ツール。

  "make oldconfig" 既存の ./.config ファイルの内容に基づいてすべての質問をデフォルトとし、新しい設定シンボルについて尋ねます。

  "make silentoldconfig" 上と同様ですが、既に回答済みの質問で画面を乱雑にするのを避けます。 さらに依存関係を更新します。

  "make olddefconfig" 上と同様ですが、新しいシンボルをプロンプトなしでデフォルト値に設定します。

  "make defconfig" アーキテクチャに応じて、arch/$ARCH/defconfig または arch/$ARCH/configs/${PLATFORM}_defconfig のデフォルトシンボル値を使用して ./.config ファイルを作成します。

  "make ${PLATFORM}_defconfig" arch/$ARCH/configs/${PLATFORM}_defconfig のデフォルトシンボル値を使用して ./.config ファイルを作成します。 使用可能なすべてのプラットフォームのリストを取得するには "make help" を使用してください。

  "make allyesconfig" シンボル値を可能な限り 'y' に設定して ./.config ファイルを作成します。

  "make allmodconfig" シンボル値を可能な限り 'm' に設定して ./.config ファイルを作成します。

  "make allnoconfig" シンボル値を可能な限り 'n' に設定して ./.config ファイルを作成します。

  "make randconfig" シンボル値をランダムな値に設定して ./.config ファイルを作成します。

  "make localmodconfig" 現在の設定とロードされたモジュール（lsmod）に基づいて設定を作成します。ロードされたモジュールに不要なモジュールオプションを無効にします。

  root@kitploit:~

                      別のマシン用の localmodconfig を作成するには、そのマシンの lsmod をファイルに保存し、LSMOD パラメータとして渡します。
  
              target$ lsmod > /tmp/mylsmod
              target$ scp /tmp/mylsmod host:/tmp
  
              host$ make LSMOD=/tmp/mylsmod localmodconfig
  
                      上記はクロスコンパイル時にも機能します。
  

  "make localyesconfig" localmodconfig と似ていますが、すべてのモジュールオプションを組み込み (=y) オプションに変換します。

  Linux カーネル設定ツールの使用方法の詳細については、Documentation/kbuild/kconfig.txt を参照してください。

• "make config" に関する注意：

  • 不要なドライバがあるとカーネルが大きくなり、状況によっては問題を引き起こす可能性があります：存在しないコントローラカードのプローブが他のコントローラを混乱させる可能性があります

  • "Processor type" を 386 より高く設定してカーネルをコンパイルすると、386 では動作しないカーネルになります。カーネルは起動時にこれを検出し、諦めます。

  • 数学エミュレーションを組み込んでコンパイルしたカーネルでも、コプロセッサが存在する場合はそれを使用します：その場合、数学エミュレーションは決して使用されません。カーネルは少し大きくなりますが、数学コプロセッサの有無にかかわらず異なるマシンで動作します。

  • "kernel hacking" 設定の詳細は、通常、より大きく遅いカーネル（またはその両方）をもたらし、いくつかのルーチンを積極的に壊れたコードを試してカーネル問題を見つけるように設定することで、カーネルを不安定にすることさえあります（kmalloc()）。したがって、"development"、"experimental"、または "debugging" 機能に関する質問には 'n' と答えるべきでしょう。

カーネルのコンパイル：

• 少なくとも gcc 3.2 が利用可能であることを確認してください。 詳細については Documentation/Changes を参照してください。

  このカーネルでは、引き続き a.out ユーザープログラムを実行できることに注意してください。

• "make" を実行して、圧縮されたカーネルイメージを作成します。lilo がカーネル makefile に適合するようにインストールされていれば、"make install" を実行することも可能ですが、最初に特定の lilo セットアップを確認することをお勧めします。

  実際のインストールを行うには root になる必要がありますが、通常のビルドでは root は必要ありません。root の名前を軽々しく使わないでください。

• カーネルの一部を modules として設定した場合は、"make modules_install" も実行する必要があります。

• 詳細なカーネルコンパイル/ビルド出力：

  通常、カーネルビルドシステムはかなり静かなモードで動作します（ただし完全に沈黙しているわけではありません）。しかし、あなたや他のカーネル開発者が、コンパイル、リンク、その他のコマンドを実行されたまま正確に確認する必要がある場合があります。そのためには、"verbose" ビルドモードを使用します。これは "make" コマンドに "V=1" を挿入することで行います。例：

  make V=1 all

  ビルドシステムに各ターゲットの再ビルド理由も表示させるには、"V=2" を使用します。デフォルトは "V=0" です。

• 問題が発生した場合に備えて、バックアップカーネルを手元に用意してください。これは特に開発リリースの場合に当てはまります。各新リリースにはデバッグされていない新しいコードが含まれているからです。そのカーネルに対応するモジュールのバックアップも忘れずに保持してください。現在動作しているカーネルと同じバージョン番号の新しいカーネルをインストールする場合は、"make modules_install" を実行する前に、モジュールディレクトリのバックアップを作成してください。

  あるいは、コンパイル前にカーネル設定オプション "LOCALVERSION" を使用して、通常のカーネルバージョンに一意のサフィックスを追加します。LOCALVERSION は "General Setup" メニューで設定できます。

• 新しいカーネルを起動するには、カーネルイメージ（例：コンパイル後 .../linux/arch/i386/boot/bzImage）を通常の起動可能なカーネルがある場所にコピーする必要があります。

• LILO などのブートローダの支援なしでフロッピーから直接カーネルを起動することは、もはやサポートされていません。

  ハードドライブから Linux を起動する場合、おそらく LILO を使用しており、/etc/lilo.conf ファイルで指定されたカーネルイメージを使用します。カーネルイメージファイルは通常 /vmlinuz、/boot/vmlinuz、/bzImage、または /boot/bzImage です。新しいカーネルを使用するには、古いイメージのコピーを保存し、新しいイメージを古いイメージに上書きコピーします。その後、LILO を再実行してローディングマップを更新する必要があります！！実行しないと、新しいカーネルイメージを起動できません。

  LILO の再インストールは通常 /sbin/lilo を実行するだけです。新しいカーネルが動作しない場合に備えて、古いカーネルイメージ（例：/vmlinux.old）のエントリを /etc/lilo.conf に指定したい場合があります。詳細については LILO のドキュメントを参照してください。

  LILO を再インストールしたら、準備は完了です。システムをシャットダウンし、再起動してお楽しみください！

  カーネルイメージ内のデフォルトのルートデバイス、ビデオモード、ramdisk サイズなどを変更する必要がある場合は、'rdev' プログラム（または必要に応じて LILO ブートオプション）を使用してください。これらのパラメータを変更するためにカーネルを再コンパイルする必要はありません。

• 新しいカーネルで再起動してお楽しみください。

問題が発生した場合：

• カーネルのバグに起因すると思われる問題がある場合は、ファイル MAINTAINERS をチェックして、問題が発生しているカーネルの部分に関連する特定の人物がいるかどうかを確認してください。そこに誰も記載されていない場合は、次善の策として私（[email protected]）にメールし、場合によっては他の関連するメーリングリストやニュースグループにも送信してください。

• すべてのバグレポートでは、必ず どのカーネルについて話しているのか、問題を再現する方法、およびセットアップは何か（常識的に判断してください）を教えてください。問題が新しいものであればその旨を伝え、古い問題であれば最初に気づいた時期を教えてください。

• バグにより、次のようなメッセージが表示される場合

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  またはそれに類似したカーネルデバッグ情報が画面またはシステムログに表示された場合は、それを 正確に 複製してください。ダンプはあなたには理解不能に見えるかもしれませんが、問題のデバッグに役立つ情報が含まれています。ダンプの上のテキストも重要です：カーネルがなぜコードをダンプしたかについて何かを示しています（上記の例では、不正なカーネルポインタが原因です）。ダンプの解釈に関する詳細情報は Documentation/oops-tracing.txt にあります。

• CONFIG_KALLSYMS を有効にしてカーネルをコンパイルした場合は、ダンプをそのまま送信できます。それ以外の場合は、ダンプを解釈するために "ksymoops" プログラムを使用する必要があります（ただし、CONFIG_KALLSYMS を有効にしてコンパイルすることが通常推奨されます）。このユーティリティは以下からダウンロードできます： ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ 。 あるいは、ダンプのルックアップを手動で行うこともできます：

• 上記のようなデバッグダンプでは、EIP 値が何を意味するかを調べることが非常に役立ちます。16進値そのものは私や他の誰にもあまり役立ちません：それはあなたの特定のカーネルセットアップに依存します。あなたがすべきことは、EIP 行から16進値を取り（"0010:" は無視）、カーネル namelist で調べて、問題のアドレスを含むカーネル関数を見つけることです。

  カーネル関数名を見つけるには、症状を示したカーネルに関連付けられたシステムバイナリを見つける必要があります。これはファイル 'linux/vmlinux' です。namelist を抽出し、カーネルクラッシュからの EIP と照合するには、以下を実行します：

  nm vmlinux | sort | less

  これにより、昇順にソートされたカーネルアドレスのリストが得られ、そこから問題のアドレスを含む関数を簡単に見つけることができます。カーネルデバッグメッセージによって与えられるアドレスは、関数アドレスと必ずしも正確に一致するとは限らないことに注意してください（実際、それは非常にまれです）。したがって、リストを 'grep' するだけではいけません。ただし、リストは各カーネル関数の開始点を提供します。したがって、検索しているアドレスより低い開始アドレスを持ち、その後に高いアドレスを持つ関数が続く関数を探すことで、目的の関数が見つかります。実際、問題レポートに少しの「コンテキスト」を含め、興味のある行の周りの数行を提供することは良い考えかもしれません。

  何らかの理由で上記ができない場合（事前コンパイルされたカーネルイメージなど）、セットアップについて可能な限り多くの情報を教えてください。詳細については REPORTING-BUGS ドキュメントをお読みください。

• あるいは、実行中のカーネルで gdb を使用することもできます（読み取り専用；つまり値を変更したりブレークポイントを設定したりすることはできません）。これを行うには、最初に -g を付けてカーネルをコンパイルします。arch/i386/Makefile を適切に編集し、次に "make clean" を実行します。また、CONFIG_PROC_FS を有効にする必要があります（"make config" 経由）。

  新しいカーネルで再起動した後、"gdb vmlinux /proc/kcore" を実行します。これで、通常の gdb コマンドをすべて使用できます。システムがクラッシュしたポイントを調べるコマンドは "l *0xXXXXXXXX" です。（XXX を EIP 値に置き換えてください。）

  現在のところ、実行していないカーネルを gdb でデバッグすることは失敗します。なぜなら gdb が（誤って）カーネルがコンパイルされた開始オフセットを無視するからです。