CVE-2023-54090
CriticalCVSS 9.8Exploitation Probability (EPSS)
Low risk41th percentile - higher than 41% of all known CVEs
Summary
In the Linux kernel, a vulnerability in the ixgbe driver causes a system panic during XDP_TX on machines with more than 64 CPUs. The issue stems from incorrect indexing of XDP TX rings, which does not apply the modulo 64 limit, leading to an out-of-bounds array access and NULL pointer dereference. Additionally, the locking mechanism (ixgbe_xdp_locking_key) is incorrectly decremented during configuration changes, allowing the bug to trigger.
Risk Assessment
The risk involves a potential kernel panic on servers with more than 64 cores when using XDP programs in XDP_TX mode. This can disrupt network services and cause system unavailability, especially critical in production environments.
Recommendation
It is recommended to immediately update the Linux kernel to a version containing the fix for CVE-2023-54090. If updating is not possible, avoid using XDP_TX on systems with more than 64 CPUs or limit the number of active cores to 64.
Other vulnerabilities in Linux kernel
See all- CVE-2026-93204Unknown
In the Linux kernel, the batman-adv module's dat handling updated MAC addresses using a simple copy, which could be partially observed by parallel readers. A reader might transport a half-updated MAC address over the network or use it in ARP responses, poisoning the ARP cache. The fix uses atomic64_t to store the 48-bit MAC address, ensuring readers see either the old or new address, never a mixture.
- CVE-2026-93202Unknown
A bug in the Linux kernel's I3C subsystem causes recursive locking during registration of new I3C devices. The function i3c_master_register_new_i3c_devs() registers devices while holding i3c_bus_normaluse_lock(), and device_register() can immediately trigger a probe callback that tries to acquire the same lock again, leading to a deadlock. The fix separates device creation from registration and uses the maintenance lock.
- CVE-2026-93200Unknown
The Linux kernel's i3c master subsystem had a use-after-free vulnerability in the master->this pointer. Sysfs attribute callbacks dereferenced master->this, which was freed in i3c_master_detach_free_devs() before the master device was released. The fix keeps master->this alive until i3c_masterdev_release() and resets it on error paths.
- CVE-2026-93199Unknown
In the Linux kernel, the i3c_master_search_i3c_dev_duplicate() function that searches for duplicate I3C devices can incorrectly match the master device itself (master->this), returning the controller as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. The fix excludes master->this from matching.
- CVE-2026-93198Unknown
In the Linux kernel, the dm-pcache module does not validate the persisted dirty_tail chain at load. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, causing cache_writeback_fn() to re-arm itself forever. The fix adds validation of the dirty_tail chain at load with a hop cap.
- CVE-2026-93197Unknown
A bug in the Linux kernel's memcg subsystem causes LRU size accounting to be copied to the parent instead of moved when a memory cgroup is offlined, leaving stale counters on the child. This makes the LRU (or MGLRU) scanner read phantom sizes and grind through empty lists on dying cgroups, over-budgeting limits and wasting CPU. On one host, counters described 476 GiB of pages—1.89x the machine's RAM.
- CVE-2026-93195Unknown
In the Linux kernel, the drm/bridge synopsys dw-dp driver initializes and registers the DisplayPort AUX channel during dw_dp_bind(), but never unregisters it. This may lead to resource leaks and/or use-after-free. The fix adds the missing dw_dp_unbind() function to allow cleanup.
- CVE-2026-93194Unknown
In the Linux kernel, the drm/rockchip dw_dp driver initializes and registers core resources such as the DisplayPort AUX channel during dw_dp_bind(), but never unregisters them. This leads to memory leaks and/or use-after-free, as shown in a KASAN report. The issue is fixed by using the exported dw_dp_unbind() function in the component's unbind() callback and in its bind() error path.
- CVE-2026-93193Unknown
In the Linux kernel, the drm/rockchip analogix_dp driver has an OF node reference leak in rockchip_dp_drm_encoder_enable(), because of_get_child_by_name() does not call of_node_put() symmetrically. The fix uses __free(device_node) to automatically manage reference release.
- CVE-2026-93191Unknown
In the Linux kernel, smack_msg_queue_msgrcv() incorrectly checks permissions of the 'current' task instead of the 'target' task. In the pipelined_send() optimization path, the sender checks on behalf of the receiver, so an unauthorized receiver can get the message, violating Smack MAC policy. The fix checks permissions on the 'target' task.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ixgbe: Fix panic during XDP_TX with > 64 CPUs Commit 4fe815850bdc ("ixgbe: let the xdpdrv work with more than 64 cpus") adds support to allow XDP programs to run on systems with more than 64 CPUs by locking the XDP TX rings and indexing them using cpu % 64 (IXGBE_MAX_XDP_QS). Upon trying this out patch on a system with more than 64 cores, the kernel paniced with an array-index-out-of-bounds at the return in ixgbe_determine_xdp_ring in ixgbe.h, which means ixgbe_determine_xdp_q_idx was just returning the cpu instead of cpu % IXGBE_MAX_XDP_QS. An example splat: ========================================================================== UBSAN: array-index-out-of-bounds in /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26 index 65 is out of range for type 'ixgbe_ring *[64]' ========================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 65 PID: 408 Comm: ksoftirqd/65 Tainted: G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020 RIP: 0010:ixgbe_xmit_xdp_ring+0x1b/0x1c0 [ixgbe] Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 <44> 0f b7 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0 RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282 RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000 RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000 RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001 R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000 R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ixgbe_poll+0x103e/0x1280 [ixgbe] ? sched_clock_cpu+0x12/0xe0 __napi_poll+0x30/0x160 net_rx_action+0x11c/0x270 __do_softirq+0xda/0x2ee run_ksoftirqd+0x2f/0x50 smpboot_thread_fn+0xb7/0x150 ? sort_range+0x30/0x30 kthread+0x127/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x30 </TASK> I think this is how it happens: Upon loading the first XDP program on a system with more than 64 CPUs, ixgbe_xdp_locking_key is incremented in ixgbe_xdp_setup. However, immediately after this, the rings are reconfigured by ixgbe_setup_tc. ixgbe_setup_tc calls ixgbe_clear_interrupt_scheme which calls ixgbe_free_q_vectors which calls ixgbe_free_q_vector in a loop. ixgbe_free_q_vector decrements ixgbe_xdp_locking_key once per call if it is non-zero. Commenting out the decrement in ixgbe_free_q_vector stopped my system from panicing. I suspect to make the original patch work, I would need to load an XDP program and then replace it in order to get ixgbe_xdp_locking_key back above 0 since ixgbe_setup_tc is only called when transitioning between XDP and non-XDP ring configurations, while ixgbe_xdp_locking_key is incremented every time ixgbe_xdp_setup is called. Also, ixgbe_setup_tc can be called via ethtool --set-channels, so this becomes another path to decrement ixgbe_xdp_locking_key to 0 on systems with more than 64 CPUs. Since ixgbe_xdp_locking_key only protects the XDP_TX path and is tied to the number of CPUs present, there is no reason to disable it upon unloading an XDP program. To avoid confusion, I have moved enabling ixgbe_xdp_locking_key into ixgbe_sw_init, which is part of the probe path.