Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%

CVE-2023-54090— ixgbe: Fix panic during XDP_TX with > 64 CPUs

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于ixgbe_determine_xdp_q_idx返回错误索引,可能导致数组索引越界和空指针取消引用。

CVSS 9.8 · Critical EPSS 0.59% · P47

Possible ATT&CK Techniques 1 AI

T1055 · Process Injection

Affected Version Matrix 10

VendorProduct Version RangeStatus
Linux Linux 4fe815850bdc8d4cc94e06fe1de069424a895826< 1924450175349e64f8dfc3689efcb653dba0418e affected
4fe815850bdc8d4cc94e06fe1de069424a895826< 785b2b5b47b1aa4c31862948b312ea845401c5ec affected
4fe815850bdc8d4cc94e06fe1de069424a895826< 4cd43a19900d0b98c1ec4bb6984763369d2e19ec affected
4fe815850bdc8d4cc94e06fe1de069424a895826< c23ae5091a8b3e50fe755257df020907e7c029bb affected
5.16 affected
< 5.16 unaffected
6.1.29≤ 6.1.* unaffected
6.2.16≤ 6.2.* unaffected
… +2 more rows
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2023-54090

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
ixgbe: Fix panic during XDP_TX with > 64 CPUs
Source: CVE Program / CVE List V5
Vulnerability Description
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.
Source: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于ixgbe_determine_xdp_q_idx返回错误索引,可能导致数组索引越界和空指针取消引用。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 4fe815850bdc8d4cc94e06fe1de069424a895826 ~ 1924450175349e64f8dfc3689efcb653dba0418e -
Linux Linux 5.16 -

II. Public POCs for CVE-2023-54090

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2023-54090

请登录查看更多情报信息。

Other References for CVE-2023-54090 (1)

Same Patch Batch · Linux · 2025-12-24 · 322 CVEs total

CVE-2025-68741 9.8 CRITICAL scsi: qla2xxx: Fix improper freeing of purex item
CVE-2023-53867 9.8 CRITICAL ceph: fix potential use-after-free bug when trimming caps
CVE-2025-68726 9.8 CRITICAL crypto: aead - Fix reqsize handling
CVE-2025-68745 9.8 CRITICAL scsi: qla2xxx: Clear cmds after chip reset
CVE-2023-54094 9.8 CRITICAL net: prevent skb corruption on frag list segmentation
CVE-2023-54076 9.8 CRITICAL smb: client: fix missed ses refcounting
CVE-2022-50717 9.8 CRITICAL nvmet-tcp: add bounds check on Transfer Tag
CVE-2025-68359 9.8 CRITICAL btrfs: fix double free of qgroup record after failure to add delayed ref head
CVE-2023-53996 9.3 CRITICAL x86/sev: Make enc_dec_hypercall() accept a size instead of npages
CVE-2023-54071 8.8 HIGH wifi: rtw88: use work to update rate to avoid RCU warning
CVE-2023-54120 8.8 HIGH Bluetooth: Fix race condition in hidp_session_thread
CVE-2023-54043 8.8 HIGH iommufd: Do not add the same hwpt to the ioas->hwpt_list twice
CVE-2022-50732 8.8 HIGH staging: rtl8192u: Fix use after free in ieee80211_rx()
CVE-2023-54092 8.8 HIGH KVM: s390: pv: fix index value of replaced ASCE
CVE-2023-54060 8.8 HIGH iommufd: Set end correctly when doing batch carry
CVE-2023-54040 8.8 HIGH ice: fix wrong fallback logic for FDIR
CVE-2025-68736 8.8 HIGH landlock: Fix handling of disconnected directories
CVE-2023-53986 8.6 HIGH mips: bmips: BCM6358: disable RAC flush for TP1
CVE-2022-50746 8.4 HIGH erofs: validate the extent length for uncompressed pclusters
CVE-2025-68365 8.2 HIGH fs/ntfs3: Initialize allocated memory before use

Showing top 20 of 322 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

V. Comments for CVE-2023-54090

No comments yet


Leave a comment