Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
linux-4.1.15_CVE-2023-4128 | Kitploit
ツール/GitHubGitHub/trinadh465/linux-4.1.15_cve-2023-4128
脆弱性分析エクスプロイトバイナリ解析論文と研究学習と教育
GitHubtrinadh465/linux-4.1.15_cve-2023-4128

linux-4.1.15_CVE-2023-4128

リポジトリを見る
2年前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

Linux カーネル リリース 4.x http://kernel.org/

これは Linux バージョン 4 のリリースノートです。注意深くお読みください。 これらは、これが何であるか、カーネルのインストール方法、問題が発生した場合の 対処方法を説明しています。

Linux とは何か?

Linux は、Unix オペレーティングシステムのクローンであり、Linus Torvalds が ネットワーク上の緩やかに結びついたハッカーたちのチームの支援を受けて ゼロから書きました。POSIX および Single UNIX Specification への準拠を 目指しています。

真のマルチタスク、仮想メモリ、共有ライブラリ、デマンドローディング、 共有コピーオンライト実行ファイル、適切なメモリ管理、IPv4 および IPv6 を 含むマルチスタックネットワーキングなど、現代の本格的な Unix に期待される すべての機能を備えています。

GNU General Public License に基づいて配布されています。詳細については、 同梱の COPYING ファイルを参照してください。

どのようなハードウェアで動作しますか?

当初は 32 ビット x86 ベースの PC(386 以降)向けに最初に開発されましたが、 今日の Linux は(少なくとも)Compaq Alpha AXP、Sun SPARC および UltraSPARC、Motorola 68000、PowerPC、PowerPC64、ARM、Hitachi SuperH、Cell、 IBM S/390、MIPS、HP PA-RISC、Intel IA-64、DEC VAX、AMD x86-64、AXIS CRIS、 Xtensa、Tilera TILE、AVR32、Renesas M32R の各アーキテクチャでも動作します。

Linux は、ページング式メモリ管理ユニット(PMMU)と GNU C コンパイラ(gcc) (GNU Compiler Collection、GCC の一部)の移植版があれば、ほとんどの汎用 32 ビットまたは 64 ビットアーキテクチャに容易に移植できます。Linux は PMMU の ないアーキテクチャにも移植されていますが、その場合の機能は明らかにいくぶん 制限されます。 Linux はまた、それ自体にも移植されています。カーネルをユーザー空間 アプリケーションとして実行できます。これは UserMode Linux(UML)と呼ばれます。

ドキュメント:

  • インターネット上の電子形式と書籍の両方で、Linux 固有のものから一般的な UNIX の疑問に関するものまで、多くのドキュメントが入手できます。LDP(Linux Documentation Project)の書籍については、任意の Linux FTP サイトの ドキュメントサブディレクトリを調べることをお勧めします。この README は システムのドキュメントを意図したものではありません。もっと優れた情報源が あります。

  • Documentation/ サブディレクトリにはさまざまな README ファイルがあります。 これらには通常、たとえば一部のドライバに関するカーネル固有のインストール メモが含まれています。各ファイルに含まれる内容の一覧は Documentation/00-INDEX を参照してください。Changes ファイルには、カーネルのアップグレードによって 発生する可能性のある問題に関する情報が含まれているため、必ずお読みください。

  • Documentation/DocBook/ サブディレクトリには、カーネル開発者とユーザー向けの ガイドがいくつか含まれています。これらのガイドは、PostScript(.ps)、PDF、 HTML、man ページなど、さまざまな形式で出力できます。インストール後、 "make psdocs"、"make pdfdocs"、"make htmldocs"、または "make mandocs" を 実行すると、要求された形式でドキュメントが出力されます。

カーネルソースのインストール:

  • 完全なソースをインストールする場合は、カーネルの tarball を権限のある ディレクトリ(例: ホームディレクトリ)に置いて、展開してください:

    xz -cd linux-4.X.tar.xz | tar xvf -

    "X" は最新カーネルのバージョン番号に置き換えてください。

    /usr/src/linux 領域を使用しないでください! この領域には、ライブラリの ヘッダファイルが使用する(通常は不完全な)カーネルヘッダ一式があります。 これらはライブラリと一致している必要があり、その時々のカーネルによって 壊されてはなりません。

  • パッチを適用して 4.x リリース間をアップグレードすることもできます。パッチは xz 形式で配布されています。パッチによるインストールを行うには、新しい パッチファイルをすべて取得し、カーネルソースのトップレベルディレクトリ (linux-4.X)に入って、次を実行してください:

    xz -cd ../patch-4.x.xz | patch -p1

    現在のソースツリーのバージョン "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 番目の引数として別のディレクトリを指定 できます。

  • 古い .o ファイルや依存関係が残っていないことを確認してください:

    cd linux make mrproper

    これでソースが正しくインストールされたはずです。

ソフトウェア要件

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

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

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

root@kitploit:~
 カーネルソースコード: /usr/src/linux-4.X
 ビルドディレクトリ:    /home/name/build/kernel

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

root@kitploit:~
 cd /usr/src/linux-4.X
 make O=/home/name/build/kernel menuconfig
 make O=/home/name/build/kernel
 sudo make O=/home/name/build/kernel modules_install install

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

カーネルの設定:

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

  • 代替の設定コマンドは次のとおりです:

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

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

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

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

    "make gconfig" X Window (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" を実行してください。カーネルの makefile に適合する lilo がインストールされている場合は "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 を実行するだけです。新しいカーネル イメージが動作しない場合に備えて、古いカーネルイメージ(たとえば /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:" は 無視)、カーネルのネームリストでそれを調べて、どのカーネル関数が問題のアドレスを 含んでいるかを確認することです。

    カーネル関数名を見つけるには、症状を示したカーネルに関連付けられたシステム バイナリを見つける必要があります。これは 'linux/vmlinux' ファイルです。 ネームリストを抽出してカーネルクラッシュの 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 が(誤って)カーネルがコンパイルされたときの開始オフセットを無視するため です。

ツールをダウンロード