kernel-5.14.0-427.18.1.el9_4
エラータID: AXSA:2024-8445:16
リリース日:
2024/06/24 Monday - 11:09
題名:
kernel-5.14.0-427.18.1.el9_4
影響のあるチャネル:
MIRACLE LINUX 9 for x86_64
Severity:
Moderate
Description:
以下項目について対処しました。
[Security Fix]
- net/netfilter/nf_tables_api.c の nf_tables_newset() 関数
には、本来指定が許容されない NFT_SET_TIMEOUT
フラグと NFT_SET_ANONYMOUS フラグの組み合わせ
のチェック処理が欠落しているため、ローカルの攻撃者
により、サービス拒否攻撃を可能とする脆弱性が存在
します。(CVE-2024-26642)
- net/netfilter/nf_tables_api.c の nf_tables_unbind_set()
関数には、フラグの設定処理が欠落しているため、
ローカルの攻撃者により、サービス拒否攻撃を可能とする
脆弱性が存在します。(CVE-2024-26643)
- net/netfilter/nft_ct.c の nft_ct_expect_obj_init() 関数には、
入力されたプロトコル番号などのチェック処理が欠落して
いるため、ローカルの攻撃者により、情報の漏洩、および
サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-26673)
- net/ipv4/ip_tunnel.c には、バッファーオーバーフローの
問題があるため、ローカルの攻撃者により、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2024-26804)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2024-26642
In the Linux kernel, the following vulnerability has been resolved: 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.
In the Linux kernel, the following vulnerability has been resolved: 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.
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.
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.
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.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-5.14.0-427.18.1.el9_4.src.rpm
MD5: 75dc65e1cce1c4e9ca07db634fabfa52
SHA-256: 784c4ae74f7100caaa7ab9fed2345dba3771452901b2501d2b0cc14a35f60916
Size: 143.82 MB
Asianux Server 9 for x86_64
- bpftool-7.3.0-427.18.1.el9_4.x86_64.rpm
MD5: 1b523c0db00ef314f0b10f2ecdebce0e
SHA-256: f0e8ae5c173ac4f02e59a4a9b8de52f7ea9a877223c4abfa24b30ce56d445a48
Size: 6.08 MB - kernel-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 3cd8755325666939727227caa2d653b9
SHA-256: bed006a4f0d5568ee54f133d97c953655e796b6b2682004343361bf1b315167b
Size: 5.31 MB - kernel-abi-stablelists-5.14.0-427.18.1.el9_4.noarch.rpm
MD5: 3e5a88512ddd3038483a2f4fc65f3a23
SHA-256: 9c78e602c7fa86ac9922f877da04cddc1ffefa9120763c64d88049f3f43311f8
Size: 5.33 MB - kernel-core-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: d7e8ba47223e0b7abeb3faf3ed23930d
SHA-256: e53154464a2f906c2923cc35f4f23f118af31fd5e88d08179cb3d00a03bf65a7
Size: 20.18 MB - kernel-cross-headers-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 53be659278e530712148c2e9984f61a7
SHA-256: 66953c96063b991b724d91dbce5a3603c342112adec3eabdfaafc01a2bf85324
Size: 11.91 MB - kernel-debug-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: fb1f05fcbb96b0ebae9b91e56225a100
SHA-256: 551e15224ffc1a60413e9c70ed92b38610b3f6157acd679888bfc4f0976987a9
Size: 5.31 MB - kernel-debug-core-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: b37c0320666e7d9860c1315df663ce65
SHA-256: 3c5ab92a557d6dce858f1f2fc5df674254cd89b70021c7650e6da6b6b0de6c26
Size: 32.83 MB - kernel-debug-devel-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: a72dca12b111f04516d1d93da49e600f
SHA-256: 6c94320927d2c371542d6ea9c201fc2416a4f794702f950b3f80b52ecc91bfcb
Size: 24.53 MB - kernel-debug-devel-matched-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 479616aecec0d85dbec669f7312199dc
SHA-256: f535298bbf95ab182fdba3b2060f0a57de0d1b40dcaede6e523a74c76204fd7b
Size: 5.31 MB - kernel-debug-modules-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 7100c04116215cf2ed592444de15e5a6
SHA-256: bcc70431844fe57443c3e457c81cf8370149c6e70aa2e5f68f74fddafa200f51
Size: 64.29 MB - kernel-debug-modules-core-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 1a11b1ab295dd4d9ffb2a81657a1510c
SHA-256: 38bb835dfb1e35a88652317e70baefbc245d7ab22ce95847c955e78a91434b3c
Size: 50.35 MB - kernel-debug-modules-extra-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 6b0550b1c5ba9bec8de10444f1054b37
SHA-256: c3ebc0340c96ac6f37e5dbd47408fb65dc472b5708f1819f3a808d17bed50beb
Size: 6.15 MB - kernel-debug-uki-virt-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 5f9dc9a750230e3326aae42d0f23c77e
SHA-256: 63067e3bb8d43f262dc2ba1ffe4d5ae34415f01366159d8d484249ced6c90f4f
Size: 82.14 MB - kernel-devel-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 3c1504dbee34169cebfbaef9b88b6e69
SHA-256: 0bef9eb66d048728b0975759b01b228133dedf7ff2ee26661f80f47c30ca7bbf
Size: 24.36 MB - kernel-devel-matched-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: c6242662b6ceb830902be13e22276a18
SHA-256: 0b17a5c2a2eca19b753c13774da001d0d9528e449818a1bcfcfd0b339ff69795
Size: 5.31 MB - kernel-doc-5.14.0-427.18.1.el9_4.noarch.rpm
MD5: f29b9940dcc4e9fe5da2511d6e242b3e
SHA-256: 9e95042e1e607e514c26b3658ea2b7252b362b63c0b8d0e5c696829093471243
Size: 38.74 MB - kernel-headers-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: e65834edf733dc7330a7b53300a792ef
SHA-256: 50ef5188ba9422b0367504d076002b5ee54c1c8948141274934c39b960193c7b
Size: 6.99 MB - kernel-modules-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 65cb2127e0d901f051750f28fd040841
SHA-256: c9ac8eab9037ea4ba21a71cab67ce890ab1f83e2f0fbbc3d0dfc47bac82b57a1
Size: 38.92 MB - kernel-modules-core-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 38cfeb58b8d641e727876515fc71474c
SHA-256: 2bc3a09bf3324d1177bbf755802817878b245c453d6bc370b1b59f2e8577d486
Size: 33.04 MB - kernel-modules-extra-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 9be1f370c2b4233024b9beeca90567fa
SHA-256: d036741405129a383ca3ef051978309618d0e9517efa4825d3eea00f6bdb9b25
Size: 5.77 MB - kernel-tools-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: a044134f56f2e1edac9af708088ce43b
SHA-256: ac3f18f2417d5be04c282943fa7c64cf625a4e5534c835898e1e21f7f630bcab
Size: 5.57 MB - kernel-tools-libs-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 6f73243708c5bf21b2f7531321fbfa5a
SHA-256: 325cfe2f4f5b517a8548b4d25c1e91d0987711ad90dac377d584b1c78d9b58bb
Size: 5.33 MB - kernel-tools-libs-devel-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 5634bc40a2a9d032ea7d507c1359f431
SHA-256: 9834d0cd5ca82017cad3637e346897bddd9acfe35ac4d7cf4350653b7c91b4d0
Size: 5.32 MB - kernel-uki-virt-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: ec7b70ea721ecdafebe6bbf73e835228
SHA-256: 6b6a754cbd209b61f2dcccf65b9b4f857b97842925f10022ea9ac911218fc184
Size: 62.04 MB - libperf-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 0157d04975c3fa8f5eac50e6b0fda960
SHA-256: 0576d10bbfc12f5deb1e92bd230a296108b3dee22ceb4a0e33e244a494cb9bf8
Size: 5.33 MB - perf-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: aeffcb253701d647ae0b1e0b55550cb3
SHA-256: 11f3ce55ab2d94999cf4bda98f645cce7842606291420051846014c4c9e8fc25
Size: 7.34 MB - python3-perf-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 2167d21255739e7ae130a7d9e049cdc1
SHA-256: 0067c94806f486619b74fe31b75b3772ad420240e15af6b2a49d790daf0cb155
Size: 5.41 MB - rtla-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 90c3901dc5765ba1b5037ac979228d9b
SHA-256: 6fba0282b67d2d1f87d45434ba617c52ac012346c636e76b4187b17bfff7b763
Size: 5.36 MB - rv-5.14.0-427.18.1.el9_4.x86_64.rpm
MD5: 31a7d2709365ab86e33b3f63be325455
SHA-256: 794f083a1915d9365c5b3fa1c7006e0e6cba22fee31f1ca367d7f3f7aba38f6b
Size: 5.33 MB