MiracleLinux 9kernel-5.14.0-427.18.1.el9_4AXSA:2024-8445:16
high Nessus プラグイン ID 292527
Language:
概要
リモートのMiracleLinuxホストに1つ以上のセキュリティ更新プログラムがありません。説明
リモートのMiracleLinux 9ホストには、AXSA:2024-8445:16アドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。* kernel: netfilter: nf_tables: タイムアウトのある匿名のセットのバインドを解除する際に、セットをデッドとしてマークします (CVE-2024-26643)
* kernel: netfilter: nf_tables: タイムアウトフラグのある匿名セットを許可しません (CVE-2024-26642)
* kernel: netfilter: nft_ct: カスタムの期待値で、レイヤー 3 と 4 のプロトコル番号をサニタイズします (CVE-2024-26673)
* カーネルnetip_tunnel永久的なヘッドルームの増加を防止CVE-2024-26804CVE-2024-26642 Linux カーネルで、以下の脆弱性が解決されました netfilter: nf_tables: disallow anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
CVE-2024-26643 In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path.
Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 (netfilter: nf_tables: use timestamp to check for set element timeout). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case.
According to 08e4c8c5919f (netfilter: nf_tables: mark newset as dead on transaction abort), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.
CVE-2024-26673 In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.
CVE-2024-26804 In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline]
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
__netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ...
but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets adjusted by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.
Tenableは、前述の記述ブロックをMiracleLinuxセキュリティアドバイザリから直接抽出しています。
Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。
ソリューション
影響を受けるパッケージを更新してください。参考資料
プラグインの詳細
深刻度: High
ID: 292527
ファイル名: miracle_linux_AXSA-2024-8445.nasl
バージョン: 1.1
タイプ: local
公開日: 2026/1/20
更新日: 2026/1/20
サポートされているセンサー: Nessus Agent, Nessus
リスク情報
VPR
リスクファクター: Medium
スコア: 6.0
Vendor
Vendor Severity: Moderate
CVSS v2
リスクファクター: Medium
基本値: 6.2
現状値: 4.6
ベクトル: CVSS2#AV:L/AC:L/Au:S/C:C/I:N/A:C
CVSS スコアのソース: CVE-2024-26673
CVSS v3
リスクファクター: High
基本値: 7.1
現状値: 6.2
ベクトル: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
現状ベクトル: CVSS:3.0/E:U/RL:O/RC:C
脆弱性情報
CPE: p-cpe:/a:miracle:linux:kernel-modules, p-cpe:/a:miracle:linux:rv, p-cpe:/a:miracle:linux:kernel-uki-virt, p-cpe:/a:miracle:linux:rtla, p-cpe:/a:miracle:linux:kernel-tools-libs-devel, p-cpe:/a:miracle:linux:kernel-debug-modules-core, p-cpe:/a:miracle:linux:kernel-devel, p-cpe:/a:miracle:linux:kernel-core, p-cpe:/a:miracle:linux:kernel-abi-stablelists, p-cpe:/a:miracle:linux:kernel-modules-extra, p-cpe:/a:miracle:linux:kernel-debug, p-cpe:/a:miracle:linux:kernel-tools-libs, p-cpe:/a:miracle:linux:perf, p-cpe:/a:miracle:linux:libperf, p-cpe:/a:miracle:linux:kernel-debug-modules, p-cpe:/a:miracle:linux:kernel-debug-devel, p-cpe:/a:miracle:linux:kernel-cross-headers, p-cpe:/a:miracle:linux:kernel-tools, p-cpe:/a:miracle:linux:kernel-modules-core, cpe:/o:miracle:linux:9, p-cpe:/a:miracle:linux:kernel-debug-devel-matched, p-cpe:/a:miracle:linux:kernel, p-cpe:/a:miracle:linux:kernel-debug-uki-virt, p-cpe:/a:miracle:linux:kernel-devel-matched, p-cpe:/a:miracle:linux:python3-perf, p-cpe:/a:miracle:linux:bpftool, p-cpe:/a:miracle:linux:kernel-headers, p-cpe:/a:miracle:linux:kernel-debug-core, p-cpe:/a:miracle:linux:kernel-debug-modules-extra
必要な KB アイテム: Host/local_checks_enabled, Host/cpu, Host/MiracleLinux/release, Host/MiracleLinux/rpm-list
エクスプロイトの容易さ: No known exploits are available
パッチ公開日: 2024/6/24
脆弱性公開日: 2021/7/21
参照情報
CVE: CVE-2024-26642, CVE-2024-26643, CVE-2024-26673, CVE-2024-26804