kernel-5.14.0-427.24.1.el9_4
エラータID: AXSA:2024-8559:21
リリース日:
2024/07/16 Tuesday - 11:02
題名:
kernel-5.14.0-427.24.1.el9_4
影響のあるチャネル:
MIRACLE LINUX 9 for x86_64
Severity:
Moderate
Description:
以下項目について対処しました。
[Security Fix]
- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c の
hns3_nic_net_open() 関数には、デバイスのリセット処理と
TC のセットアップ処理間のレースコンディションに起因
して当該関数が複数回呼び出されてしまう問題があるため、
ローカルの攻撃者により、サービス拒否攻撃を可能とする
脆弱性が存在します。(CVE-2021-47400)
- mlx5e ネットワークデバイスドライバーには、演算子の
優先順位の誤りに起因するメモリ領域の範囲外アクセスの
問題があるため、ローカルの攻撃者により、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2023-52626)
- drivers/net/ethernet/mellanox/mlx5/core/en/fs_tt_redirect.c
の fs_any_create_groups() 関数には、メモリ領域の二重解放
の問題があるため、ローカルの攻撃者により、サービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2023-52667)
- Bluetooth HCI サブシステムの net/bluetooth/hci_core.c の
hci_error_reset() 関数には、HCI_EV_HARDWARE_ERROR
イベントの処理中に Bluetooth コントローラーが応答しない
場合におけるメモリ領域の解放後利用の問題があるため、
ローカルの攻撃者により、サービス拒否攻撃を可能とする
脆弱性が存在します。(CVE-2024-26801)
- drivers/crypto/qat/qat_common/adf_aer.c の PCI AER
システムのエラーリカバリ処理には、reset_data 構造体の
解放処理のレースコンディションに起因した解放後利用の
問題があるため、ローカルの攻撃者により、デバイスの
再起動処理を介して、情報の漏洩、およびサービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2024-26974)
- drivers/net/xen-netfront.c の xennet_alloc_one_rx_buffer()
関数には、skb_mark_for_recycle() 関数の呼び出しの欠落に
起因したメモリリークの問題があるため、ローカルの攻撃者
により、サービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-27393)
- fs/smb/client/connect.c の smb2_reconnect_server() 関数
には、レースコンディションに起因するメモリ領域の解放後
利用の問題があるため、ローカルの攻撃者により、サービス
拒否攻撃を可能とする脆弱性が存在します。
(CVE-2024-35870)
- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c の
add_rule_fg() 関数には、ルールの追加処理時の処理に問題
があるため、ローカルの攻撃者により、フローグループの
削除を介して、サービス拒否攻撃 (クラッシュの発生) を
可能とする脆弱性が存在します。(CVE-2024-35960)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2021-47400
In the Linux kernel, the following vulnerability has been resolved: net: hns3: do not allow call hns3_nic_net_open repeatedly hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set.
In the Linux kernel, the following vulnerability has been resolved: net: hns3: do not allow call hns3_nic_net_open repeatedly hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set.
CVE-2023-52626
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix operation precedence bug in port timestamping napi_poll context Indirection (*) is of lower precedence than postfix increment (++). Logic in napi_poll context would cause an out-of-bound read by first increment the pointer address by byte address space and then dereference the value. Rather, the intended logic was to dereference first and then increment the underlying value.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix operation precedence bug in port timestamping napi_poll context Indirection (*) is of lower precedence than postfix increment (++). Logic in napi_poll context would cause an out-of-bound read by first increment the pointer address by byte address space and then dereference the value. Rather, the intended logic was to dereference first and then increment the underlying value.
CVE-2023-52667
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a potential double-free in fs_any_create_groups When kcalloc() for ft->g succeeds but kvzalloc() for in fails, fs_any_create_groups() will free ft->g. However, its caller fs_any_create_table() will free ft->g again through calling mlx5e_destroy_flow_table(), which will lead to a double-free. Fix this by setting ft->g to NULL in fs_any_create_groups().
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a potential double-free in fs_any_create_groups When kcalloc() for ft->g succeeds but kvzalloc() for in fails, fs_any_create_groups() will free ft->g. However, its caller fs_any_create_table() will free ft->g again through calling mlx5e_destroy_flow_table(), which will lead to a double-free. Fix this by setting ft->g to NULL in fs_any_create_groups().
CVE-2024-26801
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth
CVE-2024-26974
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.
CVE-2024-27393
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks").
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks").
CVE-2024-35870
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in smb2_reconnect_server() The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING. To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down. The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc: kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in smb2_reconnect_server() The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING. To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down. The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc: kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace:
CVE-2024-35960
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-5.14.0-427.24.1.el9_4.src.rpm
MD5: 704e51390db605e3bf924d5db81569bd
SHA-256: b218570022b85ccd0fbedb4d30098820c18a6eae978efa19e36c8d0ecc417c3f
Size: 138.52 MB
Asianux Server 9 for x86_64
- bpftool-7.3.0-427.24.1.el9_4.x86_64.rpm
MD5: 381ecbd2321b97aedc758e7504f547b0
SHA-256: d761d7786f6e992f076d19237b6e3eb50305185849a274395c5d4ec11eb1ac4f
Size: 5.87 MB - kernel-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 0e3ce9f1fc3f6d96ee9ccc950b4b21b4
SHA-256: 0feed88e653bbcd895986df3647766b7064377f25c59241ffb87254585e3b299
Size: 5.10 MB - kernel-abi-stablelists-5.14.0-427.24.1.el9_4.noarch.rpm
MD5: 2baec4abc7e0d1b3d58f4131a9274df5
SHA-256: 88e6ffd08469ac844fab8a125b1ea0dc1c3e8610fee4aeb08ce7801b5e56713f
Size: 5.12 MB - kernel-core-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: bea2b9a71bce768abfa662f3a1379f82
SHA-256: 800b7ee6df3c543e8ab20712722147e589bbf8c4f04566da1271848f04be6e42
Size: 19.97 MB - kernel-cross-headers-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 0f4882a6bd0677b87f3a0da58b314a73
SHA-256: 851e5654be4495a614b524d64fc200d062c81ab0a8efbe2c956a19546fb6d516
Size: 11.70 MB - kernel-debug-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: bf94d8d8c2a88bf1a1447380381c22a4
SHA-256: 0ec51c32f16a04f347cdab07de72f8f95630f150dfa6389dc4ba2aca140a3f1e
Size: 5.10 MB - kernel-debug-core-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: c46cb9d18400fc51206dee85310a01c1
SHA-256: 7f52bab1fd114059226fd1618a7969732d924df7cc7bab8a21d56f8112c5e120
Size: 32.64 MB - kernel-debug-devel-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 3b8d5f2e13e2330ac03b8bca122e9e01
SHA-256: e8af9688d0fa735338cb424e3401caec9430ec241b27de5ca7d174cd9d3abfcd
Size: 24.32 MB - kernel-debug-devel-matched-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: bcdb070d0cd336d3153f921eedfe5ac1
SHA-256: f5d2052ed7f26650bf54b8cd58ccfde1c0b71c4451868abbcf0aae4862e9b4ee
Size: 5.10 MB - kernel-debug-modules-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 2cbeb0b7c7b65f4034886b967c8d36ab
SHA-256: 2951412d2d019821e2badefd11aa433fa5c8555343d780962d6f2f519c5798d3
Size: 64.09 MB - kernel-debug-modules-core-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 0b35665e9f1a9ba329c2a36e093d630a
SHA-256: 90fd1fb7764fb4e700fe95d7e34a7b229f6d6cc9055975eb78e6a5b9d0bf4d15
Size: 50.24 MB - kernel-debug-modules-extra-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 91e898c160ff139abf6be163e7e22e29
SHA-256: 81170060b2eb4d9948e5709c5cb2ddec3938b4b4300970f99d52d68f3b91836d
Size: 5.94 MB - kernel-debug-uki-virt-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 27af9af55c7e003e39312d2d871c2591
SHA-256: da1a5c777aaa935780ab37b1660d05cab69cf66556b46d33e53fbdb821d8f29e
Size: 81.95 MB - kernel-devel-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: cd03fd8859a019c1c136ddf0b7c602b3
SHA-256: f6df26a60a5a936580c3d4f91321bd5096c3dfa7802ffb9364e8744e3c2f0265
Size: 24.15 MB - kernel-devel-matched-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 2db9cde16c07fb0a191d1e74cf506cd3
SHA-256: d74da0f51f025c76d0f2a66c262c958186accef38141a459d764a5a1e7b3c83d
Size: 5.10 MB - kernel-doc-5.14.0-427.24.1.el9_4.noarch.rpm
MD5: 887977211db0f899af6331a5807c5921
SHA-256: d226a019f51d97805237e6f700418c98fbeb996daedaf057806a84f6f3453e38
Size: 38.54 MB - kernel-headers-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: c0bb655513ff2c4aae2a56bc6f232478
SHA-256: f159baa8ff9c4402cd7a439d78744967badfd396996f5ababff0e5e5c5a81a84
Size: 6.78 MB - kernel-modules-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 4288c192aa6429cc0fbb3b39cab70ffe
SHA-256: 829065281e008f2fcafaacde4bd33f1f8459d4e21096e91df0cf3f565689d27e
Size: 38.70 MB - kernel-modules-core-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: f95e8304e584b5ef001ccccceef343af
SHA-256: 08e6dae8b876aafff470721a40dafa33d652c86ef5ce274df91f9219a64817e5
Size: 32.90 MB - kernel-modules-extra-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 1e7c5110992fe26b3b05f3ceefb695db
SHA-256: bc3b58da1e386714f8624355f6fea5242f957c38eb7929a377fad9db10c8f551
Size: 5.56 MB - kernel-tools-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: e3ead4eb4b9c150e6355b05537acfcf0
SHA-256: 2dc670e0e8ea42a9bb9a474a0eeff8005053953b38c710b88efeaf4eda5e49cf
Size: 5.36 MB - kernel-tools-libs-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 511354d243798d80f57952e9fe243ffc
SHA-256: 6b07d07591bfdc03f1696a209e6cba1c7ebbeccfeb6dd5f02cd0d1d32152dfca
Size: 5.12 MB - kernel-tools-libs-devel-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: e84bca15736da9e9b72e2fe91e4f64f2
SHA-256: ade34780bb4f1b699618d3359328628ca813cd53244e3579b9cf3905083140bd
Size: 5.11 MB - kernel-uki-virt-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: f1fbb066d65b39d76bbe6b7bb567c169
SHA-256: 78c372bd500cfadedfbe3194340d093f5473ab559d06f1cd7be5d881849e34da
Size: 61.83 MB - libperf-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 2836b25dc575af35d2b661d7a0f5a744
SHA-256: 4b04ed1e6b7e837dd7bf9cf117958df6a65af12df9914eb4eabcd4c46e2e784b
Size: 5.12 MB - perf-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 289e54d0dd3bed438e357d6cc7cb1b79
SHA-256: c0e5344eb115b4713d68eaa9a127bcfab249888e394468021a0015ba7a6f5e00
Size: 7.13 MB - python3-perf-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 66372f8cfb144a45ce03cddf23cfd0d2
SHA-256: 8c650b0f4f7d168ae2c681a567027c586339629556837c99afbea28d955bae7d
Size: 5.20 MB - rtla-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 5052887589cb99cb494af1cdff6dfc21
SHA-256: 94de1b4a8825b9209377f010d5d2eaa0a6b439033ccc38a906f94260ee514c75
Size: 5.15 MB - rv-5.14.0-427.24.1.el9_4.x86_64.rpm
MD5: 512136c9d1288152c16629ec12d5c4f9
SHA-256: 4edb4628e220e2ce6178bea03f66ecdde835686515028463e501adf644c00549
Size: 5.12 MB
English