ELSA-2026-25191を詳しく解説―Oracle Linux RHCKの7件CVEとUEK環境の確認方法

« ハブ記事「Linuxカーネル432件CVE公開ニュースから16件を洗い出した話」へ戻る

概要

2026年7月16日、Oracle Linux 10のRed Hat Compatible Kernel、通称RHCKを対象とするセキュリティ更新ELSA-2026-25191が公開されました。

Oracleによる重要度はCriticalです。更新には、ネットワークボンディング、EROFS、SocketCAN、USBオーディオ、IPv6、SELinuxとOverlayFSに関係する7件のCVEが含まれています。

7件の中には、kernel.orgのCVSS評価が9.8となっているIPv6関連の脆弱性もあります。

ただし、次のように判断してはいけません。


ELSAがCritical
    ↓
Oracle Linuxを使う全サーバーが
7件すべての攻撃を受ける

実際の影響は、次の条件で大きく変わります。

UEKとRHCKのどちらで起動しているか
ネットワークボンディングを使用しているか
EROFSをマウントしているか
CANサブシステムを使用しているか
snd_usb_6fireドライバーを使用しているか
IPv6トンネルやRPLヘッダーを処理するか
SELinuxとOverlayFSを組み合わせているか
修正版カーネルで実際に起動しているか

本記事では、7件の仕組みと成立条件を整理し、UEKで運用しているkurutann.comにとって何を確認すべきか、実務で使えるコマンドとともに解説します。

結論・要点

最初に結論をまとめます。

項目	内容
アドバイザリ	ELSA-2026-25191
対象	Oracle Linux 10のRHCK
Oracle重要度	Critical
公開日	2026年7月16日
Related CVEs	7件
修正RHCK	6.12.0-211.34.1.el10_2系列
kurutann.com	記事記載の実機ではUEKで起動
RHCKへの直接影響	実行中カーネルがUEKなら直接の実行環境ではない
注意点	同じ上流CVEがUEKにも存在する場合がある
恒久対策	利用中のカーネル系列を最新の修正版へ更新
再起動	通常のRPM更新では原則必要
WAF	原則として根本対策にならない
IPS・EDR	一部の攻撃や異常を補助検知できるが更新の代替にはならない

Oracle Linux 10のx86_64版では、UEKとRHCKが提供され、UEKが既定のカーネルです。したがって、Oracle Linuxを使用しているという情報だけでは影響を判断できません。

この記事で分かること

この記事では次の内容を解説します。

RHCKとUEKの違い
ELSA-2026-25191に含まれる7件のCVE
各CVEで何が壊れるのか
どの機能を使うと攻撃経路が成立するか
CVSS評価が情報源ごとに異なる理由
UEK環境が本当に影響を受けないか確認する方法
RHCKがインストールされている場合の注意点
カーネルの更新方法
再起動後の動作確認
WAF、IPS、EDRによる補助対策
脆弱性判定の証跡を残す方法

対象読者・前提環境

対象読者は次のとおりです。

Oracle Linux 10を使用している人
UEKまたはRHCKを運用している人
Linuxカーネルの大量CVEを仕分けたい人
DockerやPodmanを使用している人
IPv6を有効にしている人
脆弱性スキャナーでELSA-2026-25191を検出された人
実行中カーネルとインストール済みカーネルを区別したい人

コマンドは、調査対象のOracle Linuxサーバー上で実行します。

RHCKとUEKとは

RHCKとは

RHCKはRed Hat Compatible Kernelの略です。

簡単にたとえると、Red Hat Enterprise Linuxとの互換性を重視したOracle Linux向けカーネルです。

パッケージ名は主に次の形式です。


kernel
kernel-core
kernel-modules

バージョン文字列には通常、uekが含まれません。


6.12.0-211.34.1.el10_2.x86_64

UEKとは

UEKはUnbreakable Enterprise Kernelの略です。

Oracleが提供する、性能、スケーラビリティ、Oracle製品との連携などを強化したカーネルです。

パッケージ名は次です。


kernel-uek

実行中カーネルの文字列には、通常uekが含まれます。


6.12.0-xxx.el10uek.x86_64

Oracle Linux 10のx86_64版ではUEKが既定です。aarch64版ではRHCKは提供されません。

ELSA-2026-25191とは

ELSA-2026-25191は、Oracle Linux 10のRHCK向けカーネルセキュリティ更新です。

Oracleは重要度をCriticalとし、Related CVEs欄に次の7件を掲載しています。

CVE-2026-31419
CVE-2026-31467
CVE-2026-31532
CVE-2026-31581
CVE-2026-43037
CVE-2026-43501
CVE-2026-46054

これらは、同じ原因から派生した7件ではありません。

カーネルという一つのRPMに、複数サブシステムの修正が累積して含まれているため、同じアドバイザリへまとめられています。


RHCKカーネル更新
├─ bonding
├─ EROFS
├─ SocketCAN
├─ USBオーディオ
├─ IPv6トンネル
├─ IPv6 RPL
└─ SELinux・OverlayFS

7件のCVE一覧

| CVE | 対象 | 主な問題 | kernel.org系CVSS | Oracle評価 |
|---|---|---|---:|---CVSS | Oracle評価 |
|---|---|---|---:|---:|
| CVE-2026-31419 | bonding | Use-After-Free | 7.8 | 7.8 |
| CVE-2026-31467 | EROFS | I/Oデッドロック | 7.5 | 5.5 |
| CVE-2026-31532 | SocketCAN RAW | Use-After-Free | 7.8 | 7.1 |
| CVE-2026-31581 | ALSA 6fire | 切断時Use-After-Free | 7.8 | 6.3 |
| CVE-2026-43037 | IPv6トンネル | 型の取り違えによる境界外書き込み | 9.8 | 8.1 |
| CVE-2026-43501 | IPv6 RPL | headroom不足による境界外書き込み | 9.8 | 7.5 |
| CVE-2026-46054 | SELinux・OverlayFS | mmap・mprotectの権限確認不足 | 7.1 | 7.0 |

CVSS評価は、攻撃経路、必要権限、攻撃複雑性などの解釈によって異なります。特にCVE-2026-43037とCVE-2026-43501は、kernelh2turn371073search3turn891275search2

CVE-2026-31419：ネットワークボンディングのUse-After-Free

何が起きるのか

Linuxのボンディング機能は、複数のネットワークインターフェースを一つにまとめる機能です。

bond_xmit_broadcast()は、複数の配下インターフェースへ同じパケットを送信します。

修正前は、RCUで配下インターフェースを走査している途中に、別の処理がインターフェースを追加または解除すると、「最後のインターフェース」の判定が途中で変化する可能性がありました。

その結果、同じ元の`。citeturn531359view0turn631238view0


送信するskb
    │
    ├─ インターフェースAへclone
    ├─ インターフェースBへclone
    └─ 最後だけ元のskbを使用
             │
     配下一覧が途中で変化
             ↓
     「最後」の判定が重複
             ↓
      同じskbを二重解放

成立条件

主な対象候補は次の環境です。

Linux bondingを使用
broadcast送信経路を使用
配下インターフェースの追加・解除と送信が競合
未修正カーネル

通常の単一NIC構成では、該当するボンディング送信経路は使用しません。

CVE-2026-31467：EROFSのI/Oデッドロック

何が起きるのか

EROFSは、読み取り専用のイメージファイルシステムです。

組イメージなどにも利用できます。citeturn587943search1

問題は、EROFSのbio完了処理から展開処理を呼び出し、その中でvm_map_ram()がGFP_KERNELによるメモリー確保を行う点にありました。

メモリー不足時にスワップI/Oが発生すると、すでにI/O完了を待っている処理の中から、さらに。citeturn531359view1turn221835view0


EROFS読み込み
    ↓
bio完了処理
    ↓
データ展開
    ↓
メモリー不足
    ↓
スワップI/Oを要求
    ↓
既存I/Oの完了待ちと循環
    ↓
デッドロック・サービス停止

主な影響

ファイル読み込みの停止
ストレージ処理の停止
システムのハング
可CVSS 5.5と評価しています。citeturn531359view1

CVE-2026-31532：SocketCAN RAWのUse-After-Free

何が起きるのか

LinuxのSocketCANは、CANバスをネットワークソケットと同じように扱う仕組みです。

raw_release()がCAN受信フィルターを解除した後も、RCUの遅延処理によってraw_rcv()が動作し続ける時間があります。

しかし、ro->uniqというper-CPU領域が先citeturn531359view2turn371073search1

物理CAN機器は必須ではない

Linuxにはvcanという仮想CANデバイスがあります。

`vcanANフレームを送受信できます。citeturn587943search7

したがって、次の判断はできません。


CAN機器を接続していない
    ↓
必ず影響なし

確認すべきなのは次の点です。

CANカーネル機能が有効か
can_rawが読み込まれているか
vcanを含むCANインターフェースが存在するか
アプリケーションがCAN RAWソケットを使用するか

CVE-2026-31581：ALSA 6fireドライバーの切断時Use-After-Free

何が起きるのか

この脆弱性は、ALSAの6fire USBオーディオドライバーにあります。

USBデバイスの切断処理で、snd_card_free_when_closed()がカードと、その内部にあるchip構造体を同期的に解放する場合があります。

その後で`chip->card =citeturn531359view3turn891275search1

成立条件

snd_usb_6fireドライバーを使用
対応USBオーディオ機器を使用
デバイスの切断処理が発生
未修正カーネル

一般的なVPSでは、物理USBデバイスがゲストOSへ公開されていない場合が多く、攻撃経路は限定的です。

ただし、USBパススルーを使用する仮想マシンやデスクトップLinuxでは確認が必要です。

CVE-2026-43037：IPv6トンネル処理の境界外書き込み

何が起きるのか

ip4ip6_err()は、IPv6受信処理で使用されたskbを複製し、IPv4 ICMP処理へ渡します。

問題は、skb->cb[]に残っていたIPv6用の管理情報を、IPv4用の構造体として解釈した点です。

IPv6とIPv4では同じ領域のレイアウトが異なります。

その結果、攻撃者が制御できる値を長さとして読み取り、citeturn531359view4turn371073search2


IPv6受信時の管理情報
        ↓
初期化せずIPv4 ICMP処理へ渡す
        ↓
異なる構造体として解釈
        ↓
攻撃者制御値をコピー長に使用
        ↓
40バイトのスタック領域を超えて書き込み

CVSSの評価差

kernel.orgは9.8と評価しています。

一方、Oracleは攻撃複雑性をHighとciteturn371073search2turn531359view4

記事では次のように表現するのが安全です。

ネットワーク経由で成立する可能性がある重大な境界外書き込みです。ただし、IPv6トンネルとエラー生成経路などの前提条件があるため、公開されたIPv6アドレスへ任意のパケットを送るだけで、すべてのLinuxサーバーを直ちに侵害できるとは限りません。

CVE-2026-43501：IPv6 RPLヘッダー再圧縮の境界外書き込み

何が起きるのか

RPLは、主に低消費電力ネットワーク向けのIPv6ルーティング技術です。

ipv6_rpl_srh_rcv()は、受信したRPL Source Routing Headerを展開し、次の宛先へ書き換えた後、再圧縮します。

再圧縮後のヘッダーが受信時より大きくなる場合、必要なheadroomを確保しないままskb_push()を行う可能性がありました。

その後のMACヘッダー再構築で16ビット値がラップし、`skbciteturn729168view0turn371073search3


RPLヘッダー受信
    ↓
展開
    ↓
宛先アドレスを書き換え
    ↓
再圧縮後の方が大きくなる
    ↓
headroom不足
    ↓
mac_header値がラップ
    ↓
大きく離れた位置へ境界外書き込み

攻撃経路の評価差

kernel.orgはネットワーク到達可能、CVSS 9.8と評価しています。

Oracle・Red Hciteturn371073search3turn729168view0

したがって、単純に「IPv6が有効ならインターネットから未認証RCE」と表現してはいけません。

CVE-2026-46054：SELinuxとOverlayFSの権限確認不足

何が起きるのか

OverlayFSは、上位層と下位層を重ねて一つのファイルシステムとして見せる機能です。

Dockerなどのコンテナ環境でも広く使われます。

SELinuxでは、OverlayFS上のファイルへアクセスする場合、次の両方を確認する必要があります。

利用者が上位側のファイルへアクセスできるか
マウント実行者の資格情報で下位側ファイルへアクセスできるか

修正前は、mmap()とmprotect()について、下位側のbacciteturn729168view1turn891275search2


コンテナなどから見える上位ファイル
          ＋
実際の内容を持つ下位ファイル
          ↓
本来は両方へSELinuxチェック
          ↓
mmap・mprotectで下位側チェックが不足
          ↓
本来禁止されるメモリー保護操作の可能性

UEKに関する注意

OracleのCVEページで確認できる修正情報は、確認時点ではRHCKアドバイザリは掲載されていません。citeturn729168view1

このため、次のいずれかを推測で断定してはいけません。

UEKも脆弱である
UEKは影響を受けない
ELSA-2026-500004で必ず修正された

UEK環境では、Oracleの更新情報、インストール済みパッケージ、必要に応じてOracle Supportの回答を根拠に判定します。

kurutann.comに関係するか

記事に記載された実機情報では、kurutann.comはUEKで起動しています。

実行中カーネルがUEKであれば、RHCK向けのELSA-2026-25191は、現在動いているカーネルへ直接適用される更新ではありません。

ただし、次の点を分けて考えます。


RHCK向けアドバイザリ
    ↓
実行中UEKには直接適用されない

同じ上流Linux CVE
    ↓
UEKにもコードが存在する可能性がある
    ↓
UEK側のアドバイザリを別途確認

OracleのCVE情報では、今回の7件のうち6件について、UEK向け`ELSA-209view3turn531359view4turn729168view0

そのため、kurutann.comの判定は次のように書くのが正確です。

kurutann.comはUEKで起動しているため、RHCK向けELSA-2026-25191は現在の実行中カーネルへ直接適用される更新ではありません。一方、7件のうち複数はUEKにも修正が提供されています。UEKを最新の修正済みパッケージへ更新し、再起動後に実行中カーネルを確認することで対応状況を管理しています。

「RHCKだから無関係」だけで終わらせず、UEK側にも同じ修正が提供されているかを確認することが重要です。

確認方法1：実行中カーネルを確認する

目的

現在UEKとRHCKのどちらで動作しているか確認します。

実行場所

調査対象のOracle Linuxサーバーです。

コマンド


uname -r

UEKの例


6.12.0-xxx.el10uek.x86_64

RHCKの例


6.12.0-211.34.1.el10_2.x86_64

判断方法

出力にuekが含まれていれば、現在はUEKで起動しています。

含まれていなければ、RHCKである可能性があります。

確認方法2：インストール済みカーネルを確認する

目的

実行していないRHCKやUEKがディスク上に残っていないか確認します。


rpm -q kernel kernel-core kernel-uek

出力例


kernel-6.12.0-211.34.1.el10_2.x86_64
kernel-core-6.12.0-211.34.1.el10_2.x86_64
kernel-uek-6.12.0-xxx.el10uek.x86_64

UEKで起動していても、RHCKがインストールされている場合があります。

RHCKをフォールバック用に残す場合は、RHCK側の更新も継続してください。

確認方法3：GRUBの既定カーネルを確認する

目的

次回再起動時に、どのカーネルが選ばれるか確認します。


sudo grubby --default-kernel

インストール済みの起動エントリーを確認します。


sudo grubby --info ALL

Oracleは`grubり替える方法を案内しています。citeturn939084search0

判断方法

現在はUEKでも、既定カーネルがRHCKになっている場合、再起動後にRHCKへ切り替わる可能性があります。

確認方法4：7件に関係する機能を確認する

bonding


ip -d link show type bond
lsmod | grep '^bonding'

出力がなければ、ボンディングを使用していない可能性があります。

EROFS


findmnt -t erofs
grep -w erofs /proc/filesystems

/proc/filesystemsへの表示だけでは、現在マウントしているとは限りません。最終判断にはfindmntを使用します。

SocketCAN


lsmod | grep -E '^(can|can_raw|vcan)'
ip -details link show |
  grep -E '(^[0-9]+:|can |vcan)'

物理CAN機器がなくても、vcanが存在する場合があります。

ALSA 6fire


lsmod | grep snd_usb_6fire

IPv6トンネル


ip -6 tunnel show
lsmod | grep -E 'ip6_tunnel|sit'

OverlayFSとSELinux


findmnt -t overlay
getenforce

Dockerを使用している場合、OverlayFSが表示される可能性があります。

機能が使われていることは「脆弱である」という意味ではありません。カーネルの修正状態と組み合わせて判断します。

対処方法

RHCKを使用している場合

更新情報を確認します。


sudo dnf updateinfo info \
  --advisory ELSA-2026-25191

更新を適用します。


sudo dnf upgrade \
  --advisory ELSA-2026-25191

UEKを使用している場合

UEK向けのセキュリティ情報を確認します。


sudo dnf updateinfo info \
  --advisory ELSA-2026-50319

sudo dnf updateinfo info \
  --advisory ELSA-2026-50372

古いアドバイザリのパッケージへ固定するのではなく、現在利用可能な最新のUEKセキュリティ更新を適用します。


sudo dnf upgrade 'kernel-uek*'

または、OS全体のセキュリティ更新を適用します。


sudo dnf upgrade --security

更新前の注意事項

カーネル更新前に、次を準備してください。

VPSスナップショット
PostgreSQLなどのデータバックアップ
Dockerボリュームのバックアップ
プロバイダーの管理コンソール
SSH以外の復旧手段
旧カーネルがGRUBに残っていること
メンテナンス時間
再起動後の監視手順

カーネルのアンインストールや既定カーネル変更は、起動不能につながる可能性があります。

旧カーネルを削除する前に、新しいカーネルで正常起動できることを確認してください。

再起動と動作確認

再起動


sudo systemctl reboot

通常のカーネルRPM更新では、再起動するまで古いカーネルが動き続けます。

実行中カーネルの確認


uname -r

既定カーネルの確認


sudo grubby --default-kernel

失敗サービスの確認


sudo systemctl --failed

正常例です。


0 loaded units listed.

カーネルログの確認


sudo journalctl -b -p warning

確認項目は次のとおりです。

kernel panic
Use-After-Free
general protection fault
slab corruption
ネットワークインターフェースの起動失敗
Dockerの起動失敗
SELinux拒否の急増

コンテナ確認


docker ps
docker compose ps

Webサイト確認


curl -I https://kurutann.com/

構成に応じて、想定した200、301、302などが返ることを確認します。

WAF・IPS・EDRによる補助対策

WAF

一般的なWeb向けWAFは、今回の7件に対する根本対策にはなりません。

問題はLinuxカーネル内部のネットワーク、ファイルシステム、ドライバー、アクセス制御処理にあります。

IPS

CVE-2026-43037やCVE-2026-43501のようなネットワーク入力に関係する問題では、対応シグネチャがあれば補助検知できる可能性があります。

ただし、トンネル処理、断片化、拡張ヘッダーなどの条件によって検知が難しくなる可能性があります。

EDR

次の異常は監視対象になります。

カーネルクラッシュ
不審なネットワーク名前空間操作
CANインターフェースの予期しない作成
USBデバイスの不自然な切断処理
SELinux拒否の急増
コンテナからの異常なmmap・mprotect
bonding構成の予期しない変更

ただし、カーネル権限を奪われるとEDR自体を回避される可能性があります。

最優先対策はカーネル更新です。

悪用状況

2026年7月27日時点で確認したOracleおよびNVDの公開情報からは、今回の7件すべてについて、実環境での大規模な悪用を裏付ける情報は確認できませんでした。

これは、悪用されていないことを証明するものではありません。

特に境界外書き込みやUse-After-Freeは、DoSだけでなく権限昇格やコード実行へ発展する可能性がありまh2turn371073search3turn891275search2

再発防止

UEKとRHCKを資産台帳で区別する

項目	記録例
OS	Oracle Linux 10
CPU	x86_64
実行中カーネル	UEK
既定起動カーネル	UEK
RHCKインストール	あり・なし
最終カーネル更新	YYYY-MM-DD
最終再起動	YYYY-MM-DD
Ksplice	使用・未使用

非該当判定に再評価条件を付ける


判定：現在は直接影響なし
理由：UEKで起動しておりRHCKは非稼働
証跡：uname -r、grubby --default-kernel
再評価条件：
・起動カーネル変更
・RHCKへの切り替え
・OracleのUEK製品状態更新

機能ベースで確認する

カーネルCVEは、パッケージの有無だけでなく機能の利用状態を確認します。


パッケージ
   ＋
実行中カーネル
   ＋
カーネル設定
   ＋
モジュール
   ＋
実際のインターフェース・マウント
   ＋
攻撃者の到達経路

注意点・よくある誤解

UEKならRHCKのCVEはすべて無関係ですか

いいえ。

RHCK向けアドバイザリはUEKへ直接適用されませんが、同じ上流LinuxコードがUEKにも含まれる場合があります。

UEK側のOracle CVE情報とアドバイザリを確認してください。

ELSA-2026-500004を適用すれば今回の7件も対応済みですか

アドバイザリ番号だけでは証明できません。

後発のUEKパッケージは過去の修正を累積して含む可能性がありますが、実行中パッケージとCVEごとの修正情報を照合してください。

CAN機器がないのでCVE-2026-31532は無関係ですか

物理CAN機器がなくてもvcanを利用できます。

CANモジュール、仮想CANインターフェース、CANアプリケーションの有無を確認します。

IPv6が有効ならCVE-2026-43037とCVE-2026-43501が攻撃可能ですか

IPv6が有効なだけでは、成立を証明できません。

IPv6トンネル、RPLヘッダー処理、ネットワーク到達性、カーネル修正状態を確認します。

RHCKを使っていなければ更新不要ですか

RHCKをフォールバック用に残す場合は更新を継続してください。

将来RHCKへ切り替わった際に、古い脆弱なカーネルで起動する可能性があります。

まとめ

ELSA-2026-25191は、Oracle Linux 10のRHCK向けCriticalカーネル更新です。

7件のCVEは、それぞれ異なる条件で成立します。


CVE-2026-31419
  └─ bondingの競合

CVE-2026-31467
  └─ EROFSとメモリー不足時のI/O

CVE-2026-31532
  └─ CAN RAWソケット

CVE-2026-31581
  └─ 6fire USBドライバー

CVE-2026-43037
  └─ IPv6トンネルのエラー処理

CVE-2026-43501
  └─ IPv6 RPLヘッダー処理

CVE-2026-46054
  └─ SELinuxとOverlayFS

kurutann.comがUEKで起動している場合、RHCK向けELSA-2026-25191は現在の実行中カーネルへ直接適用される更新ではありません。

しかし、同じ上流CVEの多くはUEKにも修正が提供されています。

したがって、正しい結論は次のとおりです。


RHCKで起動していない
    ↓
ELSA-2026-25191は直接の実行環境ではない

ただし
    ↓
同じCVEがUEKにも存在する可能性がある
    ↓
UEK側の修正状況を確認
    ↓
最新UEKへ更新
    ↓
再起動後にuname -rで確認

CVEの影響判定と、セキュリティ更新の適用判断は分けて管理してください。

FAQ

ELSA-2026-25191は何を更新しますか

Oracle Linux 10のRHCKである`kernelよる重要度はCriticalです。citeturn758842view1

UEKとRHCKの両方がインストールされている場合はどうしますか

uname -rで現在の実行中カーネルを確認し、grubby --default-kernelで次回起動時の既定カーネルを確認します。

フォールバック用カーネルも含め、両系列を修正済みに保つのが安全です。

バージョン番号をブログへ公開しない方が安全ですか

完全なバージョンを公開しない運用は可能ですが、バージョン秘匿は根本対策ではありません。

内部では、実行中カーネル、インストール済みパッケージ、更新履歴、再起動結果を必ず保存してください。

Kspliceを使えば再起動は不要ですか

Kspliceを使用すると、対応しているセキュリティ修正を、サーバーを再起動せずに実行中のカーネルへ適用できる場合があります。

ただし、Kspliceによるライブパッチだけで対応を終えてはいけません。

ディスク上にインストールされているカーネルパッケージが古いままだと、将来サーバーを再起動した際に、修正前のカーネルで起動する可能性があります。

そのため、次の両方を実施します。


実行中のカーネル
    └─ Kspliceでライブパッチを適用

ディスク上のカーネル
    └─ dnfで修正版パッケージへ更新

UEKを使用している場合は、利用可能な修正版へ更新します。


sudo dnf upgrade 'kernel-uek*'

更新後は、インストール済みカーネルと既定の起動カーネルを確認します。


rpm -q kernel-uek
sudo grubby --default-kernel
sudo grubby --info ALL

次回の計画再起動後には、実行中カーネルも確認します。


uname -r

Kspliceは再起動を延期できる仕組みですが、ディスク上のカーネル更新や将来の再起動を不要にする仕組みではありません。

一次資料リンク

Oracle Linux Security Advisory：ELSA-2026-25191
Oracle Linux 10のRHCKを対象としたカーネルセキュリティ更新です。
Oracle Linux Security Advisory：ELSA-2026-50372
UEK向けに提供されたカーネルセキュリティ更新です。
Oracle Linux Security Advisory：ELSA-2026-50319
UEK向けに提供されたカーネルセキュリティ更新です。
Oracle Linuxドキュメント：UEKとRHCKのカーネル構成
Oracle Linuxで提供されるカーネル系列と、既定カーネルの違いを確認できます。
Oracle Linuxドキュメント：grubbyによるカーネル管理
インストール済みの起動エントリー、既定カーネル、次回起動するカーネルの確認方法を説明しています。
Linux Kernel公式ドキュメント：SocketCAN
CANソケット、CAN RAW、仮想CANインターフェースであるvcanの仕組みを確認できます。
Linux Kernel公式ドキュメント：EROFS
EROFSの用途とファイルシステムの仕組みを確認できます。