{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-46765", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-09-11T15:12:18.273Z", "datePublished": "2024-09-18T07:12:24.420Z", "dateUpdated": "2024-12-19T09:22:41.724Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-12-19T09:22:41.724Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: protect XDP configuration with a mutex\n\nThe main threat to data consistency in ice_xdp() is a possible asynchronous\nPF reset. It can be triggered by a user or by TX timeout handler.\n\nXDP setup and PF reset code access the same resources in the following\nsections:\n* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked\n* ice_vsi_rebuild() for the PF VSI - not protected\n* ice_vsi_open() - already rtnl-locked\n\nWith an unfortunate timing, such accesses can result in a crash such as the\none below:\n\n[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14\n[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18\n[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms\n[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001\n[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14\n[ +0.394718] ice 0000:b1:00.0: PTP reset successful\n[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[ +0.000045] #PF: supervisor read access in kernel mode\n[ +0.000023] #PF: error_code(0x0000) - not-present page\n[ +0.000023] PGD 0 P4D 0\n[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1\n[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021\n[ +0.000036] Workqueue: ice ice_service_task [ice]\n[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]\n[...]\n[ +0.000013] Call Trace:\n[ +0.000016] <TASK>\n[ +0.000014] ? __die+0x1f/0x70\n[ +0.000029] ? page_fault_oops+0x171/0x4f0\n[ +0.000029] ? schedule+0x3b/0xd0\n[ +0.000027] ? exc_page_fault+0x7b/0x180\n[ +0.000022] ? asm_exc_page_fault+0x22/0x30\n[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]\n[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]\n[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]\n[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]\n[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]\n[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]\n[ +0.000145] ice_rebuild+0x18c/0x840 [ice]\n[ +0.000145] ? delay_tsc+0x4a/0xc0\n[ +0.000022] ? delay_tsc+0x92/0xc0\n[ +0.000020] ice_do_reset+0x140/0x180 [ice]\n[ +0.000886] ice_service_task+0x404/0x1030 [ice]\n[ +0.000824] process_one_work+0x171/0x340\n[ +0.000685] worker_thread+0x277/0x3a0\n[ +0.000675] ? preempt_count_add+0x6a/0xa0\n[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50\n[ +0.000679] ? __pfx_worker_thread+0x10/0x10\n[ +0.000653] kthread+0xf0/0x120\n[ +0.000635] ? __pfx_kthread+0x10/0x10\n[ +0.000616] ret_from_fork+0x2d/0x50\n[ +0.000612] ? __pfx_kthread+0x10/0x10\n[ +0.000604] ret_from_fork_asm+0x1b/0x30\n[ +0.000604] </TASK>\n\nThe previous way of handling this through returning -EBUSY is not viable,\nparticularly when destroying AF_XDP socket, because the kernel proceeds\nwith removal anyway.\n\nThere is plenty of code between those calls and there is no need to create\na large critical section that covers all of them, same as there is no need\nto protect ice_vsi_rebuild() with rtnl_lock().\n\nAdd xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().\n\nLeaving unprotected sections in between would result in two states that\nhave to be considered:\n1. when the VSI is closed, but not yet rebuild\n2. when VSI is already rebuild, but not yet open\n\nThe latter case is actually already handled through !netif_running() case,\nwe just need to adjust flag checking a little. The former one is not as\ntrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of\nhardware interaction happens, this can make adding/deleting rings exit\nwith an error. Luckily, VSI rebuild is pending and can apply new\nconfiguration for us in a managed fashion.\n\nTherefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to\nindicate that ice_x\n---truncated---"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/net/ethernet/intel/ice/ice.h", "drivers/net/ethernet/intel/ice/ice_lib.c", "drivers/net/ethernet/intel/ice/ice_main.c", "drivers/net/ethernet/intel/ice/ice_xsk.c"], "versions": [{"version": "2d4238f5569722197612656163d824098208519c", "lessThan": "2f057db2fb29bc209c103050647562e60554d3d3", "status": "affected", "versionType": "git"}, {"version": "2d4238f5569722197612656163d824098208519c", "lessThan": "391f7dae3d836891fc6cfbde38add2d0e10c6b7f", "status": "affected", "versionType": "git"}, {"version": "2d4238f5569722197612656163d824098208519c", "lessThan": "2504b8405768a57a71e660dbfd5abd59f679a03f", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/net/ethernet/intel/ice/ice.h", "drivers/net/ethernet/intel/ice/ice_lib.c", "drivers/net/ethernet/intel/ice/ice_main.c", "drivers/net/ethernet/intel/ice/ice_xsk.c"], "versions": [{"version": "5.5", "status": "affected"}, {"version": "0", "lessThan": "5.5", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.51", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.10.10", "lessThanOrEqual": "6.10.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.11", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3"}, {"url": "https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f"}, {"url": "https://git.kernel.org/stable/c/2504b8405768a57a71e660dbfd5abd59f679a03f"}], "title": "ice: protect XDP configuration with a mutex", "x_generator": {"engine": "bippy-5f407fcff5a0"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2024-09-29T14:42:47.387024Z", "id": "CVE-2024-46765", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-29T14:43:01.815Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-46765", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-09-29T14:42:47.387024Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-29T14:42:51.567Z"}}], "cna": {"title": "ice: protect XDP configuration with a mutex", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "2d4238f55697", "lessThan": "2f057db2fb29", "versionType": "git"}, {"status": "affected", "version": "2d4238f55697", "lessThan": "391f7dae3d83", "versionType": "git"}, {"status": "affected", "version": "2d4238f55697", "lessThan": "2504b8405768", "versionType": "git"}], "programFiles": ["drivers/net/ethernet/intel/ice/ice.h", "drivers/net/ethernet/intel/ice/ice_lib.c", "drivers/net/ethernet/intel/ice/ice_main.c", "drivers/net/ethernet/intel/ice/ice_xsk.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.5"}, {"status": "unaffected", "version": "0", "lessThan": "5.5", "versionType": "semver"}, {"status": "unaffected", "version": "6.6.51", "versionType": "semver", "lessThanOrEqual": "6.6.*"}, {"status": "unaffected", "version": "6.10.10", "versionType": "semver", "lessThanOrEqual": "6.10.*"}, {"status": "unaffected", "version": "6.11", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["drivers/net/ethernet/intel/ice/ice.h", "drivers/net/ethernet/intel/ice/ice_lib.c", "drivers/net/ethernet/intel/ice/ice_main.c", "drivers/net/ethernet/intel/ice/ice_xsk.c"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3"}, {"url": "https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f"}, {"url": "https://git.kernel.org/stable/c/2504b8405768a57a71e660dbfd5abd59f679a03f"}], "x_generator": {"engine": "bippy-9e1c9544281a"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: protect XDP configuration with a mutex\n\nThe main threat to data consistency in ice_xdp() is a possible asynchronous\nPF reset. It can be triggered by a user or by TX timeout handler.\n\nXDP setup and PF reset code access the same resources in the following\nsections:\n* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked\n* ice_vsi_rebuild() for the PF VSI - not protected\n* ice_vsi_open() - already rtnl-locked\n\nWith an unfortunate timing, such accesses can result in a crash such as the\none below:\n\n[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14\n[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18\n[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms\n[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001\n[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14\n[ +0.394718] ice 0000:b1:00.0: PTP reset successful\n[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[ +0.000045] #PF: supervisor read access in kernel mode\n[ +0.000023] #PF: error_code(0x0000) - not-present page\n[ +0.000023] PGD 0 P4D 0\n[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1\n[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021\n[ +0.000036] Workqueue: ice ice_service_task [ice]\n[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]\n[...]\n[ +0.000013] Call Trace:\n[ +0.000016] <TASK>\n[ +0.000014] ? __die+0x1f/0x70\n[ +0.000029] ? page_fault_oops+0x171/0x4f0\n[ +0.000029] ? schedule+0x3b/0xd0\n[ +0.000027] ? exc_page_fault+0x7b/0x180\n[ +0.000022] ? asm_exc_page_fault+0x22/0x30\n[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]\n[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]\n[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]\n[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]\n[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]\n[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]\n[ +0.000145] ice_rebuild+0x18c/0x840 [ice]\n[ +0.000145] ? delay_tsc+0x4a/0xc0\n[ +0.000022] ? delay_tsc+0x92/0xc0\n[ +0.000020] ice_do_reset+0x140/0x180 [ice]\n[ +0.000886] ice_service_task+0x404/0x1030 [ice]\n[ +0.000824] process_one_work+0x171/0x340\n[ +0.000685] worker_thread+0x277/0x3a0\n[ +0.000675] ? preempt_count_add+0x6a/0xa0\n[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50\n[ +0.000679] ? __pfx_worker_thread+0x10/0x10\n[ +0.000653] kthread+0xf0/0x120\n[ +0.000635] ? __pfx_kthread+0x10/0x10\n[ +0.000616] ret_from_fork+0x2d/0x50\n[ +0.000612] ? __pfx_kthread+0x10/0x10\n[ +0.000604] ret_from_fork_asm+0x1b/0x30\n[ +0.000604] </TASK>\n\nThe previous way of handling this through returning -EBUSY is not viable,\nparticularly when destroying AF_XDP socket, because the kernel proceeds\nwith removal anyway.\n\nThere is plenty of code between those calls and there is no need to create\na large critical section that covers all of them, same as there is no need\nto protect ice_vsi_rebuild() with rtnl_lock().\n\nAdd xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().\n\nLeaving unprotected sections in between would result in two states that\nhave to be considered:\n1. when the VSI is closed, but not yet rebuild\n2. when VSI is already rebuild, but not yet open\n\nThe latter case is actually already handled through !netif_running() case,\nwe just need to adjust flag checking a little. The former one is not as\ntrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of\nhardware interaction happens, this can make adding/deleting rings exit\nwith an error. Luckily, VSI rebuild is pending and can apply new\nconfiguration for us in a managed fashion.\n\nTherefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to\nindicate that ice_x\n---truncated---"}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:46:13.085Z"}}}, "cveMetadata": {"cveId": "CVE-2024-46765", "state": "PUBLISHED", "dateUpdated": "2024-11-05T09:46:13.085Z", "dateReserved": "2024-09-11T15:12:18.273Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-09-18T07:12:24.420Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "E91CBC9D-A2A9-4D88-BB75-B296442C94A5", "versionEndExcluding": "6.6.51", "versionStartIncluding": "5.5", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "ACDEE48C-137A-4731-90D0-A675865E1BED", "versionEndExcluding": "6.10.10", "versionStartIncluding": "6.7", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*", "matchCriteriaId": "8B3CE743-2126-47A3-8B7C-822B502CF119", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*", "matchCriteriaId": "4DEB27E7-30AA-45CC-8934-B89263EF3551", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc3:*:*:*:*:*:*", "matchCriteriaId": "E0005AEF-856E-47EB-BFE4-90C46899394D", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc4:*:*:*:*:*:*", "matchCriteriaId": "39889A68-6D34-47A6-82FC-CD0BF23D6754", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc5:*:*:*:*:*:*", "matchCriteriaId": "B8383ABF-1457-401F-9B61-EE50F4C61F4F", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.11:rc6:*:*:*:*:*:*", "matchCriteriaId": "B77A9280-37E6-49AD-B559-5B23A3B1DC3D", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: protect XDP configuration with a mutex\n\nThe main threat to data consistency in ice_xdp() is a possible asynchronous\nPF reset. It can be triggered by a user or by TX timeout handler.\n\nXDP setup and PF reset code access the same resources in the following\nsections:\n* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked\n* ice_vsi_rebuild() for the PF VSI - not protected\n* ice_vsi_open() - already rtnl-locked\n\nWith an unfortunate timing, such accesses can result in a crash such as the\none below:\n\n[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14\n[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18\n[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms\n[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001\n[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14\n[ +0.394718] ice 0000:b1:00.0: PTP reset successful\n[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[ +0.000045] #PF: supervisor read access in kernel mode\n[ +0.000023] #PF: error_code(0x0000) - not-present page\n[ +0.000023] PGD 0 P4D 0\n[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1\n[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021\n[ +0.000036] Workqueue: ice ice_service_task [ice]\n[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]\n[...]\n[ +0.000013] Call Trace:\n[ +0.000016] <TASK>\n[ +0.000014] ? __die+0x1f/0x70\n[ +0.000029] ? page_fault_oops+0x171/0x4f0\n[ +0.000029] ? schedule+0x3b/0xd0\n[ +0.000027] ? exc_page_fault+0x7b/0x180\n[ +0.000022] ? asm_exc_page_fault+0x22/0x30\n[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]\n[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]\n[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]\n[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]\n[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]\n[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]\n[ +0.000145] ice_rebuild+0x18c/0x840 [ice]\n[ +0.000145] ? delay_tsc+0x4a/0xc0\n[ +0.000022] ? delay_tsc+0x92/0xc0\n[ +0.000020] ice_do_reset+0x140/0x180 [ice]\n[ +0.000886] ice_service_task+0x404/0x1030 [ice]\n[ +0.000824] process_one_work+0x171/0x340\n[ +0.000685] worker_thread+0x277/0x3a0\n[ +0.000675] ? preempt_count_add+0x6a/0xa0\n[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50\n[ +0.000679] ? __pfx_worker_thread+0x10/0x10\n[ +0.000653] kthread+0xf0/0x120\n[ +0.000635] ? __pfx_kthread+0x10/0x10\n[ +0.000616] ret_from_fork+0x2d/0x50\n[ +0.000612] ? __pfx_kthread+0x10/0x10\n[ +0.000604] ret_from_fork_asm+0x1b/0x30\n[ +0.000604] </TASK>\n\nThe previous way of handling this through returning -EBUSY is not viable,\nparticularly when destroying AF_XDP socket, because the kernel proceeds\nwith removal anyway.\n\nThere is plenty of code between those calls and there is no need to create\na large critical section that covers all of them, same as there is no need\nto protect ice_vsi_rebuild() with rtnl_lock().\n\nAdd xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().\n\nLeaving unprotected sections in between would result in two states that\nhave to be considered:\n1. when the VSI is closed, but not yet rebuild\n2. when VSI is already rebuild, but not yet open\n\nThe latter case is actually already handled through !netif_running() case,\nwe just need to adjust flag checking a little. The former one is not as\ntrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of\nhardware interaction happens, this can make adding/deleting rings exit\nwith an error. Luckily, VSI rebuild is pending and can apply new\nconfiguration for us in a managed fashion.\n\nTherefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to\nindicate that ice_x\n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: proteger la configuraci\u00f3n de XDP con un mutex La principal amenaza a la consistencia de los datos en ice_xdp() es un posible reinicio asincr\u00f3nico de PF. Puede ser activado por un usuario o por el controlador de tiempo de espera de TX. El c\u00f3digo de configuraci\u00f3n de XDP y de restablecimiento de PF accede a los mismos recursos en las siguientes secciones: * ice_vsi_close() en ice_prepare_for_reset() - ya bloqueado en RTNL * ice_vsi_rebuild() para PF VSI - no protegido * ice_vsi_open() - ya bloqueado en RTNL Con un momento desafortunado, dichos accesos pueden resultar en un bloqueo como el siguiente: [ +1.999878] ice 0000:b1:00.0: Modelo de memoria XDP registrado MEM_TYPE_XSK_BUFF_POOL en el anillo Rx 14 [ +2.002992] ice 0000:b1:00.0: Modelo de memoria XDP registrado MEM_TYPE_XSK_BUFF_POOL en el anillo Rx 18 [15 de marzo 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: la cola de transmisi\u00f3n 14 agot\u00f3 el tiempo de espera 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout nivel de recuperaci\u00f3n 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: restablecimiento de PTP exitoso [ +0.006184] ERROR: puntero NULL del n\u00facleo desreferencia, direcci\u00f3n: 0000000000000098 [ +0.000045] #PF: acceso de lectura de supervisor en modo kernel [ +0.000023] #PF: error_code(0x0000) - p\u00e1gina no presente [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 No contaminado 6.8.0-rc7 #1 [ +0.000031] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 26/08/2021 [ +0.000036] Cola de trabajo: hielo ice_service_task [hielo] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [hielo] [...] [ +0.000013] Rastreo de llamadas: [ +0.000016] [ +0.000014] ? __die+0x1f/0x70 [ +0.000029] ? page_fault_oops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? exc_page_fault+0x7b/0x180 [ +0.000022] ? asm_exc_page_fault+0x22/0x30 [ +0.000031] ? hielo_limpio_tx_ring+0xa/0xd0 [hielo] [ +0.000194] hielo_libre_tx_ring+0xe/0x60 [hielo] [ +0.000186] hielo_destruir_xdp_rings+0x157/0x310 [hielo] [ +0.000151] hielo_vsi_decfg+0x53/0xe0 [hielo] [ +0.000180] hielo_vsi_rebuild+0x239/0x540 [hielo] [ +0.000186] hielo_vsi_rebuild_by_type+0x76/0x180 [hielo] [ +0.000145] hielo_rebuild+0x18c/0x840 [hielo] [ +0.000145] ? retraso_tsc+0x4a/0xc0 [ +0.000022] ? retraso_tsc+0x92/0xc0 [ +0.000020] hielo_do_reset+0x140/0x180 [hielo] [ +0.000886] hielo_servicio_tarea+0x404/0x1030 [hielo] [ +0.000824] proceso_una_obra+0x171/0x340 [ +0.000685] subproceso_trabajador+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? La forma anterior de manejar esto mediante la devoluci\u00f3n de -EBUSY no es viable, particularmente cuando se destruye el socket AF_XDP, porque el n\u00facleo procede con la eliminaci\u00f3n de todos modos. Hay mucho c\u00f3digo entre esas llamadas y no hay necesidad de crear una gran secci\u00f3n cr\u00edtica que las cubra todas, al igual que no hay necesidad de proteger ice_vsi_rebuild() con rtnl_lock(). Agregue el mutex xdp_state_lock para proteger ice_vsi_rebuild() y ice_xdp(). Dejar secciones desprotegidas en el medio dar\u00eda como resultado dos estados que deben considerarse: 1. cuando el VSI est\u00e1 cerrado, pero a\u00fan no se reconstruye 2. cuando VSI ya se est\u00e1 reconstruyendo, pero a\u00fan no est\u00e1 abierto El \u00faltimo caso en realidad ya se maneja a trav\u00e9s del caso !netif_running(), solo necesitamos ajustar un poco la verificaci\u00f3n de indicadores. El primero no es tan trivial, porque entre ice_vsi_close() y ice_vsi_rebuild(), ocurre mucha interacci\u00f3n de hardware, esto puede hacer que agregar/eliminar anillos salga con un error. Afortunadamente, la reconstrucci\u00f3n de VSI est\u00e1 pendiente y puede aplicar una nueva configuraci\u00f3n para nosotros de manera administrada. ---truncado---"}], "id": "CVE-2024-46765", "lastModified": "2024-09-26T13:24:29.697", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "[email protected]", "type": "Primary"}]}, "published": "2024-09-18T08:15:04.710", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/2504b8405768a57a71e660dbfd5abd59f679a03f"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-476"}], "source": "[email protected]", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: ice: protect XDP configuration with a mutex", "id": "2313113", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2313113"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.7", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-362", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nice: protect XDP configuration with a mutex\nThe main threat to data consistency in ice_xdp() is a possible asynchronous\nPF reset. It can be triggered by a user or by TX timeout handler.\nXDP setup and PF reset code access the same resources in the following\nsections:\n* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked\n* ice_vsi_rebuild() for the PF VSI - not protected\n* ice_vsi_open() - already rtnl-locked\nWith an unfortunate timing, such accesses can result in a crash such as the\none below:\n[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14\n[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18\n[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms\n[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001\n[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14\n[ +0.394718] ice 0000:b1:00.0: PTP reset successful\n[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[ +0.000045] #PF: supervisor read access in kernel mode\n[ +0.000023] #PF: error_code(0x0000) - not-present page\n[ +0.000023] PGD 0 P4D 0\n[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1\n[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021\n[ +0.000036] Workqueue: ice ice_service_task [ice]\n[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]\n[...]\n[ +0.000013] Call Trace:\n[ +0.000016] <TASK>\n[ +0.000014] ? __die+0x1f/0x70\n[ +0.000029] ? page_fault_oops+0x171/0x4f0\n[ +0.000029] ? schedule+0x3b/0xd0\n[ +0.000027] ? exc_page_fault+0x7b/0x180\n[ +0.000022] ? asm_exc_page_fault+0x22/0x30\n[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]\n[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]\n[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]\n[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]\n[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]\n[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]\n[ +0.000145] ice_rebuild+0x18c/0x840 [ice]\n[ +0.000145] ? delay_tsc+0x4a/0xc0\n[ +0.000022] ? delay_tsc+0x92/0xc0\n[ +0.000020] ice_do_reset+0x140/0x180 [ice]\n[ +0.000886] ice_service_task+0x404/0x1030 [ice]\n[ +0.000824] process_one_work+0x171/0x340\n[ +0.000685] worker_thread+0x277/0x3a0\n[ +0.000675] ? preempt_count_add+0x6a/0xa0\n[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50\n[ +0.000679] ? __pfx_worker_thread+0x10/0x10\n[ +0.000653] kthread+0xf0/0x120\n[ +0.000635] ? __pfx_kthread+0x10/0x10\n[ +0.000616] ret_from_fork+0x2d/0x50\n[ +0.000612] ? __pfx_kthread+0x10/0x10\n[ +0.000604] ret_from_fork_asm+0x1b/0x30\n[ +0.000604] </TASK>\nThe previous way of handling this through returning -EBUSY is not viable,\nparticularly when destroying AF_XDP socket, because the kernel proceeds\nwith removal anyway.\nThere is plenty of code between those calls and there is no need to create\na large critical section that covers all of them, same as there is no need\nto protect ice_vsi_rebuild() with rtnl_lock().\nAdd xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().\nLeaving unprotected sections in between would result in two states that\nhave to be considered:\n1. when the VSI is closed, but not yet rebuild\n2. when VSI is already rebuild, but not yet open\nThe latter case is actually already handled through !netif_running() case,\nwe just need to adjust flag checking a little. The former one is not as\ntrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of\nhardware interaction happens, this can make adding/deleting rings exit\nwith an error. Luckily, VSI rebuild is pending and can apply new\nconfiguration for us in a managed fashion.\nTherefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to\nindicate that ice_x\n---truncated---"], "name": "CVE-2024-46765", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-09-18T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-46765\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-46765\nhttps://lore.kernel.org/linux-cve-announce/2024091844-CVE-2024-46765-1b8f@gregkh/T"], "threat_severity": "Low"}