linux-4.1.15_CVE-2017-1000371

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 を参照してください。これらのパッケージの古すぎるバージョンを使用すると、追跡が非常に困難な間接的なエラーが発生する可能性があるため、ビルドや操作中に明らかな問題が発生した場合にパッケージを更新すればよいと想定しないでください。

カーネルのビルドディレクトリ:

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

カーネルの設定とビルドを行うには、以下を使用します：

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

カーネルの設定:

マイナーバージョンアップグレードのみの場合でも、この手順を省略しないでください。各リリースで新しい設定オプションが追加されており、設定ファイルが期待どおりに設定されていないと、奇妙な問題が発生します。最小限の作業で既存の設定を新しいバージョンに引き継ぎたい場合は、"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) に基づいて config を作成します。ロードされたモジュールに不要なモジュールオプションを無効にします。

  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 を使用しているでしょう。LILO は /etc/lilo.conf ファイルで指定されたカーネルイメージを使用します。カーネルイメージファイルは通常 /vmlinuz、/boot/vmlinuz、/bzImage、または /boot/bzImage です。新しいカーネルを使用するには、古いイメージのコピーを保存し、新しいイメージを古いイメージに上書きコピーします。その後、ローディングマップを更新するために LILO を再実行する必要があります！！ 実行しないと、新しいカーネルイメージを起動できません。

  LILO の再インストールは、通常 /sbin/lilo を実行するだけです。新しいカーネルが動作しない場合に備えて、/etc/lilo.conf を編集して古いカーネルイメージ（例：/vmlinux.old）のエントリを指定することもできます。詳細は 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 が（誤って）カーネルがコンパイルされた開始オフセットを無視するため、失敗します。