Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 在 Linux 核心中，已解決下列弱點： dpll: fix possible deadlock during netlink dump operation Recently, I've been hitting following deadlock warning during dpll pin dump:
    [52804.637962] ====================================================== [52804.638536] WARNING: possible circular locking dependency detected [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted [52804.639529]
    ------------------------------------------------------ [52804.640104] python3/2984 is trying to acquire lock: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780 [52804.641417] but task is already holding lock: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20 [52804.642747] which lock already depends on the new lock. [52804.643551] the existing dependency chain (in reverse order) is: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}:
    [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578]
    __netlink_dump_start+0x321/0x450 [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742]
    __sock_sendmsg+0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.652650] check_prev_add+0x1ae/0x1280 [52804.653107] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984]
    __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654845]
    __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg+0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendmsg+0x36d/0x660 [52804.658022]
    __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184/0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.660281] other info that might help us debug this: [52804.661077] Possible unsafe locking scenario:
    [52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] lock(dpll_lock); [52804.662924] lock(nlk_cb_mutex-GENERIC); [52804.663538] lock(dpll_lock); [52804.664073] lock(nlk_cb_mutex-GENERIC);
    [52804.664490] The issue as follows: __netlink_dump_start() calls control->start(cb) with nlk->cb_mutex held. In control->start(cb) the dpll_lock is taken. Then nlk->cb_mutex is released and taken again in netlink_dump(), while dpll_lock still being held. That leads to ABBA deadlock when another CPU races with the same operation. Fix this by moving dpll_lock taking into dumpit() callback which ensures correct lock taking order. (CVE-2024-26725)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 在 Linux 内核中，已解决以下漏洞： dpll: fix possible deadlock during netlink dump operation Recently, I've been hitting following deadlock warning during dpll pin dump:
    [52804.637962] ====================================================== [52804.638536] WARNING: possible circular locking dependency detected [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted [52804.639529]
    ------------------------------------------------------ [52804.640104] python3/2984 is trying to acquire lock: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780 [52804.641417] but task is already holding lock: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20 [52804.642747] which lock already depends on the new lock. [52804.643551] the existing dependency chain (in reverse order) is: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}:
    [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578]
    __netlink_dump_start+0x321/0x450 [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742]
    __sock_sendmsg+0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.652650] check_prev_add+0x1ae/0x1280 [52804.653107] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984]
    __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654845]
    __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg+0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendmsg+0x36d/0x660 [52804.658022]
    __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184/0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.660281] other info that might help us debug this: [52804.661077] Possible unsafe locking scenario:
    [52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] lock(dpll_lock); [52804.662924] lock(nlk_cb_mutex-GENERIC); [52804.663538] lock(dpll_lock); [52804.664073] lock(nlk_cb_mutex-GENERIC);
    [52804.664490] The issue as follows: __netlink_dump_start() calls control->start(cb) with nlk->cb_mutex held. In control->start(cb) the dpll_lock is taken. Then nlk->cb_mutex is released and taken again in netlink_dump(), while dpll_lock still being held. That leads to ABBA deadlock when another CPU races with the same operation. Fix this by moving dpll_lock taking into dumpit() callback which ensures correct lock taking order. (CVE-2024-26725)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: dpll: fix possible deadlock during     netlink dump operation Recently, I've been hitting following deadlock warning during dpll pin dump:
    [52804.637962] ====================================================== [52804.638536] WARNING: possible     circular locking dependency detected [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted [52804.639529]
    ------------------------------------------------------ [52804.640104] python3/2984 is trying to acquire     lock: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780     [52804.641417] but task is already holding lock: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3},     at: dpll_lock_dumpit+0x13/0x20 [52804.642747] which lock already depends on the new lock. [52804.643551]     the existing dependency chain (in reverse order) is: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}:
    [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+0x119/0x1150 [52804.645723]     dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578]
    __netlink_dump_start+0x321/0x450 [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575]     genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/0x210 [52804.648440] genl_rcv+0x24/0x40     [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742]
    __sock_sendmsg+0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80     [52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e     [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.652650] check_prev_add+0x1ae/0x1280     [52804.653107] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984]
    __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654845]
    __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842]     genl_rcv_msg+0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40     [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendmsg+0x36d/0x660 [52804.658022]
    __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184/0x210 [52804.658877] __x64_sys_sendto+0x72/0x80     [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e     [52804.660281] other info that might help us debug this: [52804.661077] Possible unsafe locking scenario:
    [52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] lock(dpll_lock); [52804.662924]     lock(nlk_cb_mutex-GENERIC); [52804.663538] lock(dpll_lock); [52804.664073] lock(nlk_cb_mutex-GENERIC);
    [52804.664490] The issue as follows: __netlink_dump_start() calls control->start(cb) with nlk->cb_mutex     held. In control->start(cb) the dpll_lock is taken. Then nlk->cb_mutex is released and taken again in     netlink_dump(), while dpll_lock still being held. That leads to ABBA deadlock when another CPU races with     the same operation. Fix this by moving dpll_lock taking into dumpit() callback which ensures correct lock     taking order. (CVE-2024-26725)

Note that Nessus relies on the presence of the package as reported by the vendor.

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Linux カーネルにおいて、以下の脆弱性は解決されました： dpll: fix possible deadlock during netlink dump operation Recently, I've been hitting following deadlock warning during dpll pin dump:
    [52804.637962] ====================================================== [52804.638536] WARNING: possible circular locking dependency detected [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted [52804.639529]
    ------------------------------------------------------ [52804.640104] python3/2984 is trying to acquire lock: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780 [52804.641417] but task is already holding lock: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20 [52804.642747] which lock already depends on the new lock. [52804.643551] the existing dependency chain (in reverse order) is: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}:
    [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578]
    __netlink_dump_start+0x321/0x450 [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742]
    __sock_sendmsg+0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.652650] check_prev_add+0x1ae/0x1280 [52804.653107] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984]
    __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654845]
    __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg+0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendmsg+0x36d/0x660 [52804.658022]
    __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184/0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.660281] other info that might help us debug this: [52804.661077] Possible unsafe locking scenario:
    [52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] lock(dpll_lock); [52804.662924] lock(nlk_cb_mutex-GENERIC); [52804.663538] lock(dpll_lock); [52804.664073] lock(nlk_cb_mutex-GENERIC);
    [52804.664490] The issue as follows: __netlink_dump_start() calls control->start(cb) with nlk->cb_mutex held. In control->start(cb) the dpll_lock is taken. Then nlk->cb_mutex is released and taken again in netlink_dump(), while dpll_lock still being held. That leads to ABBA deadlock when another CPU races with the same operation. Fix this by moving dpll_lock taking into dumpit() callback which ensures correct lock taking order. (CVE-2024-26725)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The remote Oracle Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2024-9315 advisory.

    - memcg: protect concurrent access to mem_cgroup_idr (Rafael Aquini) [RHEL-56254] {CVE-2024-43892}
    - bnxt_en: Fix double DMA unmapping for XDP_REDIRECT (Michal Schmidt) [RHEL-57259] {CVE-2024-44984}
    - dma: fix call order in dmam_free_coherent (Eder Zulian) [RHEL-54751] {CVE-2024-43856}
    - dmaengine: idxd: Avoid unnecessary destruction of file_ida (Jerry Snitselaar) [RHEL-44508]     {CVE-2024-38629}
    - tipc: Return non-zero value from tipc_udp_addr2str() on error (Xin Long) [RHEL-55074] {CVE-2024-42284}
    - net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink (Michal Schmidt) [RHEL-57119] {CVE-2024-44970}
    - net/mlx5e: Fix CT entry update leaks of modify header context (Michal Schmidt) [RHEL-55628]     {CVE-2024-43864}
    - net/mlx5: Always drain health in shutdown callback (Michal Schmidt) [RHEL-55616] {CVE-2024-43866}
    - net/mlx5: Fix missing lock on sync reset reload (Michal Schmidt) [RHEL-55121] {CVE-2024-42268}
    - ionic: fix kernel panic in XDP_TX action (CKI Backport Bot) [RHEL-47730] {CVE-2024-40907}
    - r8169: Fix possible ring buffer corruption on fragmented Tx packets. (Izabela Bakollari) [RHEL-44037]     {CVE-2024-38586}
    - KVM: s390: fix validity interception issue when gisa is switched off (CKI Backport Bot) [RHEL-57197]     {CVE-2024-45005}
    - wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() (Jose Ignacio Tornos     Martinez) [RHEL-55579] {CVE-2024-43879}
    - wifi: mac80211: fix NULL dereference at band check in starting tx ba session (Jose Ignacio Tornos     Martinez) [RHEL-56191] {CVE-2024-43911}
    - wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() (Jose Ignacio Tornos Martinez)     [RHEL-54805] {CVE-2024-43842}
    - gfs2: Fix NULL pointer dereference in gfs2_log_flush (Andrew Price) [RHEL-51559] {CVE-2024-42079}
    - x86/mm: Fix pti_clone_pgtable() alignment assumption (Rafael Aquini) [RHEL-57170] {CVE-2024-44965}
    - bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send() (CKI Backport     Bot) [RHEL-47822] {CVE-2024-40919}
    - netfilter: tproxy: bail out if IP has been disabled on the device (Phil Sutter) [RHEL-44369]     {CVE-2024-36270}

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

リモートの Oracle Linux 9 ホストに、ELSA-2024-9315アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

    - memcg: mem_cgroup_idr への同時アクセスを保護 (Rafael Aquini 氏) [RHEL-56254] {CVE-2024-43892}
    - bnxt_en: XDP_REDIRECT に対する二重の DMA アンマッピングを修正します (Michal Schmidt 氏) [RHEL-57259] {CVE-2024-44984}
    - dma: dmam_free_ chromium における呼び出し順序を修正します (Eder Zulian 氏) [RHEL-54751] {CVE-2024-43856}
    - dmaengine: idxd: file_ida の不要な破壊を回避 (Jerry Snitselaar 氏) [RHEL-44508] {CVE-2024-38629}
    - tipc: エラー時に tipc_udp_addr2str() からゼロ以外の値を返す (Xin Long 氏) [RHEL-55074] {CVE-2024-42284}
    - net/mlx5e: SHAMPO、無効な WQ リンクリストのリンク解除を修正します (Michal Schmidt 氏) [RHEL-57119] {CVE-2024-44970}
    - net/mlx5e: ヘッダーコンテキストを変更する CT エントリ更新の漏洩を修正します (Michal Schmidt 氏) [RHEL-55628] {CVE-2024-43864}
    - net/mlx5: シャットダウンコールバックで常にヘルスをドレインします (Michal Schmidt 氏) [RHEL-55616] {CVE-2024-43866}
    - net/mlx5: 同期リセットリロードの欠落したロックを修正 (Michal Schmidt 氏) [RHEL-55121] {CVE-2024-42268}
    - ionic: XDP_TX アクションのカーネルパニックを修正 (CKI Backport Bot) [RHEL-47730] {CVE-2024-40907}
    - r8169: フラグメント化された Tx パケットのリングバッファ破損の可能性を修正します。(Izabela Bakollari) [RHEL-44037] {CVE-2024-38586}
    - KVM: s390: gisa がオフに切り替えられているときの有効性傍受の問題を修正します (CKI Backport Bot) [RHEL-57197] {CVE-2024-45005}
    - wifi: cfg80211: cfg80211_calculate_bitrate_he() の 2x996 RU 割り当てを処理します (Jose Ignacio 氏、Tornos Martinez 氏) [RHEL-55579] {CVE-2024-43879}
    - wifi: mac80211: tx ba セッションを開始する際のバンドチェックでの NULL デリファレンスを修正します (Jose Ignacio 氏、Tornos Martinez 氏) [RHEL-56191] {CVE-2024-43911}
    - wifi: rtw89: rtw89_sta_info_get_iter() の配列インデックスの誤りを修正します (Jose Ignacio 氏、Tornos Martinez 氏) [RHEL-54805] {CVE-2024-43842}
    - gfs2: gfs2_log_flush の NULL ポインターデリファレンスを修正 (Andrew Price 氏) [RHEL-51559] {CVE-2024-42079}
    - x86/mm: pti_clone_pgtable() のアライメント仮定を修正 (Rafael Aquini 氏) [RHEL-57170] {CVE-2024-44965}
    - bnxt_en: __hwrm_send() でトークンがリリースされた場合に備えて、ファームウェアメッセージのロギングを調整します (CKI Backport Bot) [RHEL-47822] {CVE-2024-40919}
    - netfilter: tproxy: IP がデバイスで無効になっている場合のベイルアウト (Phil Sutter 氏) [RHEL-44369] {CVE-2024-36270}

Tenable は、前述の記述ブロックを Oracle Linux セキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

远程 Oracle Linux 9 主机上安装的程序包受到 ELSA-2024-9315 公告中提及的多个漏洞影响。

    - memcg：保护对 mem_cgroup_idr 的并发访问 (Rafael Aquini) [RHEL-56254] {CVE-2024-43892}
    - bnxt_en：修复 XDP_REDIRECT 的双重 DMA 取消映射 (Michal Schmidt) [RHEL-57259] {CVE-2024-44984}
    - dma：修复 dmam_free_coherent 中的调用顺序 (Eder Zulian) [RHEL-54751] {CVE-2024-43856}
    - dmaengine：idxd： 避免不必要的 file_ida 破坏 (Jerry Snitselaar) [RHEL-44508] {CVE-2024-38629}
    - tipc：发生错误时从 tipc_udp_addr2str() 返回非零值 (Xin Long) [RHEL-55074] {CVE-2024-42284}
    - net/mlx5e：SHAMPO，修复无效的 WQ 链接列表取消链接 (Michal Schmidt) [RHEL-57119] {CVE-2024-44970}
    - net/mlx5e： 修复修改标头上下文的 CT 条目更新泄漏 (Michal Schmidt) [RHEL-55628] {CVE-2024-43864}
    - net/mlx5：始终耗尽关闭回调中的运行状况 (Michal Schmidt) [RHEL-55616] {CVE-2024-43866}
    net/mlx5：修复同步重置重新加载时缺少的锁定 (Michal Schmidt) [RHEL-55121] {CVE-2024-42268}
    - ionic：修复 XDP_TX 操作中的内核错误 (CKI Backport Bot) [RHEL-47730] {CVE-2024-40907}
    - r8169：修复拆分后的 Tx 数据包上可能存在的环形缓冲区损坏。(Izabela Bakollari) [RHEL-44037] {CVE-2024-38586}
    - KVM: s390：修复关闭 gisa 时的有效性拦截问题 (CKI Backport Bot) [RHEL-57197] {CVE-2024-45005}
    - wifi：cfg80211：处理 cfg80211_calculate_bitrate_he() 中的 2x996 RU 分配 (Jose Ignacio Tornos Martinez) [RHEL-55579] {CVE-2024-43879}
    - wifi: mac80211：修复启动 tx ba 会话中 band 检查时的空取消引用 (Jose Ignacio Tornos Martinez) [RHEL-56191] {CVE-2024-43911}
    - wifi：rtw89：修复 rtw89_sta_info_get_iter() 中的数组索引错误 (Jose Ignacio Tornos Martinez) [RHEL-54805] {CVE-2024-43842}
    - gfs2：修复 gfs2_log_flush 中的空指针取消引用 (Andrew Price) [RHEL-51559] {CVE-2024-42079}
    - x86/mm：修复 pti_clone_pgtable() 对齐假设 (Rafael Aquini) [RHEL-57170] {CVE-2024-44965}
    - bnxt_en：调整对 __hwrm_send() 中已发布标记的固件消息的记录 (CKI Backport Bot) [RHEL-47822] {CVE-2024-40919}
    - netfilter：tproxy：如果设备上禁用了 IP，则应退出操作 (Phil Sutter) [RHEL-44369] {CVE-2024-36270}

Tenable 已直接从 Oracle Linux 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

遠端 Oracle Linux 9 主機中安裝的套件受到 ELSA-2024-9315 公告中提及的多個弱點影響。

    - memcg：保護對 mem_cgroup_idr 的並行存取 (Rafael Aquini) [RHEL-56254] {CVE-2024-43892}
    - bnxt_en：修正 XDP_REDIRECT 的雙重 DMA 取消對應 (Michal Schmidt) [RHEL-57259] {CVE-2024-44984}
    - dma：修正 dmam_free_coherent 中的呼叫順序 (Eder Zulian) [RHEL-54751] {CVE-2024-43856}
    - dmaengine：idxd：避免 file_ida 的不必要損毀 (Jerry Snitselaar) [RHEL-44508] {CVE-2024-38629}
    - tipc：發生錯誤時，從 tipc_udp_addr2str() 傳回非零值 (Xin Long) [RHEL-55074] {CVE-2024-42284}
    - net/mlx5e：SAMPO，修正無效的 WQ 連結清單取消連結 (Michal Schmidt) [RHEL-57119] {CVE-2024-44970}
    - net/mlx5e：修正修改標頭內容的 CT 項目更新洩漏 (Michal Schmidt) [RHEL-55628] {CVE-2024-43864}
    - net/mlx5：一律排除關機回呼中的健康狀況 (Michal Schmidt) [RHEL-55616] {CVE-2024-43866}
    - net/mlx5：修正同步重設重新載入時遺漏的鎖定 (Michal Schmidt) [RHEL-55121] {CVE-2024-42268}
    - onic：修正 XDP_TX 動作中的核心錯誤 (CKI 反向移植機器人) [RHEL-47730] {CVE-2024-40907}
    - r8169：修復片段化 Tx 封包上可能發生的環緩衝區損毀。(Izabela Bakollari) [RHEL-44037] {CVE-2024-38586}
    - KVM：s390：修正 gisa 關閉時的有效性攔截問題 (CKI Backport Bot) [RHEL-57197] {CVE-2024-45005}
    - wifi：cfg80211：處理 cfg80211_calculate_bitrate_he() 中的 2x996 RU 配置 (Jose Ignacio Tornos Martinez) [RHEL-55579] {CVE-2024-43879}
    - wifi：mac80211：修正啟動 tx ba 工作階段時進行範圍檢查時的 NULL 解除參照 (Jose Ignacio Tornos Martinez) [RHEL-56191] {CVE-2024-43911}
    - wifi: rtw89：修正 rtw89_sta_info_get_iter() 中的陣列索引錯誤 (Jose Ignacio Tornos Martinez) [RHEL-54805] {CVE-2024-43842}
    - gfs2：修正 gfs2_log_flush 中的 NULL 指標解除參照 (Andrew Price) [RHEL-51559] {CVE-2024-42079}
    - x86/mm：修正 pti_clone_pgtable() 對齊假設 (Rafael Aquini) [RHEL-57170] {CVE-2024-44965}
    - bnxt_en：在 __hwrm_send() 中發布 token 的情況下，調整韌體訊息的記錄 (CKI Backport Bot) [RHEL-47822] {CVE-2024-40919}
    - netfilter：tproxy：如果 IP 已在裝置上停用，則結束 (Phil Sutter) [RHEL-44369] {CVE-2024-36270}

Tenable 已直接從 Oracle Linux 安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	Name	Product	Family	Published	Updated	Severity
210815	RHEL 9 : kernel (RHSA-2024:9315)	Nessus	Red Hat Local Security Checks	11/12/2024	8/15/2025	high
228310	Linux Distros 未修補弱點：CVE-2024-26725	Nessus	Misc.	3/5/2025	9/6/2025	medium
228310	Linux Distros 未修补的漏洞: CVE-2024-26725	Nessus	Misc.	3/5/2025	9/6/2025	medium
228310	Linux Distros Unpatched Vulnerability : CVE-2024-26725	Nessus	Misc.	3/5/2025	9/6/2025	medium
228310	Linux Distros のパッチ未適用の脆弱性: CVE-2024-26725	Nessus	Misc.	3/5/2025	9/6/2025	medium
210815	RHEL 9：kernel (RHSA-2024:9315)	Nessus	Red Hat Local Security Checks	11/12/2024	8/15/2025	high
210815	RHEL 9 : kernel (RHSA-2024:9315)	Nessus	Red Hat Local Security Checks	11/12/2024	8/15/2025	high
210815	RHEL 9：kernel (RHSA-2024:9315)	Nessus	Red Hat Local Security Checks	11/12/2024	8/15/2025	high
211575	Oracle Linux 9 : kernel (ELSA-2024-9315)	Nessus	Oracle Linux Local Security Checks	11/19/2024	9/11/2025	high
211575	Oracle Linux 9 : kernel (ELSA-2024-9315)	Nessus	Oracle Linux Local Security Checks	11/19/2024	9/11/2025	high
211575	Oracle Linux 9：内核 (ELSA-2024-9315)	Nessus	Oracle Linux Local Security Checks	11/19/2024	9/11/2025	high
211575	Oracle Linux 9：核心 (ELSA-2024-9315)	Nessus	Oracle Linux Local Security Checks	11/19/2024	9/11/2025	high

Detections

Analytics

Plugins Search

high

medium

medium

medium

medium

high

high

high

high

high

high

high