CVE-2024-46765: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-46765

In the Linux kernel, the following vulnerability has been resolved: ice: protect XDP configuration with a mutex The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. It can be triggered by a user or by TX timeout handler. XDP setup and PF reset code access the same resources in the following sections: * ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked * ice_vsi_rebuild() for the PF VSI - not protected * ice_vsi_open() - already rtnl-locked With an unfortunate timing, such accesses can result in a crash such as the one below: [ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14 [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18 [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 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 recovery level 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: PTP reset successful [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ +0.000045] #PF: supervisor read access in kernel mode [ +0.000023] #PF: error_code(0x0000) - not-present page [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1 [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000036] Workqueue: ice ice_service_task [ice] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice] [...] [ +0.000013] Call Trace: [ +0.000016] <TASK> [ +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] ? ice_clean_tx_ring+0xa/0xd0 [ice] [ +0.000194] ice_free_tx_ring+0xe/0x60 [ice] [ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice] [ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice] [ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice] [ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice] [ +0.000145] ice_rebuild+0x18c/0x840 [ice] [ +0.000145] ? delay_tsc+0x4a/0xc0 [ +0.000022] ? delay_tsc+0x92/0xc0 [ +0.000020] ice_do_reset+0x140/0x180 [ice] [ +0.000886] ice_service_task+0x404/0x1030 [ice] [ +0.000824] process_one_work+0x171/0x340 [ +0.000685] worker_thread+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? __pfx_worker_thread+0x10/0x10 [ +0.000653] kthread+0xf0/0x120 [ +0.000635] ? __pfx_kthread+0x10/0x10 [ +0.000616] ret_from_fork+0x2d/0x50 [ +0.000612] ? __pfx_kthread+0x10/0x10 [ +0.000604] ret_from_fork_asm+0x1b/0x30 [ +0.000604] </TASK> The previous way of handling this through returning -EBUSY is not viable, particularly when destroying AF_XDP socket, because the kernel proceeds with removal anyway. There is plenty of code between those calls and there is no need to create a large critical section that covers all of them, same as there is no need to protect ice_vsi_rebuild() with rtnl_lock(). Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp(). Leaving unprotected sections in between would result in two states that have to be considered: 1. when the VSI is closed, but not yet rebuild 2. when VSI is already rebuild, but not yet open The latter case is actually already handled through !netif_running() case, we just need to adjust flag checking a little. The former one is not as trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of hardware interaction happens, this can make adding/deleting rings exit with an error. Luckily, VSI rebuild is pending and can apply new configuration for us in a managed fashion. Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to indicate that ice_x ---truncated---

AI Analysis

Technical Summary

CVE-2024-46765 is a vulnerability in the Linux kernel's ice network driver, specifically related to the handling of XDP (eXpress Data Path) configuration and PF (Physical Function) reset operations. The vulnerability arises due to a race condition caused by insufficient synchronization when accessing shared resources during XDP setup and PF reset. The ice driver manages Intel Ethernet devices, and the affected code sections include ice_vsi_close(), ice_vsi_rebuild(), and ice_vsi_open(). While some of these functions are protected by rtnl_lock(), ice_vsi_rebuild() is not, leading to potential concurrent access issues. This can cause a kernel NULL pointer dereference and subsequent system crash (kernel panic), as demonstrated by the provided kernel oops log. The root cause is the lack of a mutex protecting the critical section in ice_xdp() and ice_vsi_rebuild(), which can be triggered asynchronously by user actions or TX timeout handlers. The fix involves introducing an xdp_state_lock mutex to serialize access and adding a new VSI state flag ICE_VSI_REBUILD_PENDING to manage transitional states safely. This vulnerability does not require user interaction but can be triggered by local users or automated kernel timers, leading to denial of service through system crashes. No known exploits are reported in the wild yet, and no CVSS score is assigned at the time of publication.

Potential Impact

For European organizations, the impact of CVE-2024-46765 can be significant, especially for those relying on Linux servers with Intel network adapters managed by the ice driver. The vulnerability can cause unexpected kernel crashes, leading to denial of service (DoS) conditions that disrupt critical network services, data center operations, and cloud infrastructure. Organizations running high-availability systems, telecommunications infrastructure, or financial services platforms on affected Linux kernels may experience outages or degraded performance. The vulnerability could also complicate incident response and recovery due to unpredictable system behavior. Although no direct data breach or privilege escalation is indicated, the loss of availability and potential data inconsistency during crashes can have operational and reputational consequences. Given the widespread use of Linux in European enterprises, government agencies, and service providers, this vulnerability poses a tangible risk to network stability and service continuity.

Mitigation Recommendations

European organizations should prioritize patching Linux kernels with the updated ice driver that includes the mutex protection fix for XDP configuration and PF reset. Since the vulnerability stems from a race condition, applying the official kernel patches or upgrading to a fixed kernel version is the most effective mitigation. In environments where immediate patching is not feasible, administrators can consider temporarily disabling XDP features on affected network interfaces to reduce exposure. Monitoring kernel logs for ice driver-related errors or NETDEV WATCHDOG timeouts can help detect potential exploitation attempts or instability. Additionally, implementing robust kernel crash recovery mechanisms, such as kdump and automated reboot procedures, can minimize downtime. Network segmentation and limiting local user access to systems running the vulnerable driver can reduce the risk of triggering the vulnerability. Finally, organizations should maintain up-to-date inventories of hardware and kernel versions to quickly identify affected systems.