GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2023-54090 (GCVE-0-2023-54090)

Vulnerability from cvelistv5 – Published: 2025-12-24 13:06 – Updated: 2026-08-05 09:17
VLAI
Title
ixgbe: Fix panic during XDP_TX with > 64 CPUs
Summary
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.
Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 4fe815850bdc8d4cc94e06fe1de069424a895826 , < 1924450175349e64f8dfc3689efcb653dba0418e (git)
Affected: 4fe815850bdc8d4cc94e06fe1de069424a895826 , < 785b2b5b47b1aa4c31862948b312ea845401c5ec (git)
Affected: 4fe815850bdc8d4cc94e06fe1de069424a895826 , < 4cd43a19900d0b98c1ec4bb6984763369d2e19ec (git)
Affected: 4fe815850bdc8d4cc94e06fe1de069424a895826 , < c23ae5091a8b3e50fe755257df020907e7c029bb (git)
guessed Create a notification for this product.
Linux Linux Affected: 5.16
Unaffected: 0 , < 5.16 (semver)
Unaffected: 6.1.29 , ≤ 6.1.* (semver)
Unaffected: 6.2.16 , ≤ 6.2.* (semver)
Unaffected: 6.3.3 , ≤ 6.3.* (semver)
Unaffected: 6.4 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c",
            "drivers/net/ethernet/intel/ixgbe/ixgbe_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "1924450175349e64f8dfc3689efcb653dba0418e",
              "status": "affected",
              "version": "4fe815850bdc8d4cc94e06fe1de069424a895826",
              "versionType": "git"
            },
            {
              "lessThan": "785b2b5b47b1aa4c31862948b312ea845401c5ec",
              "status": "affected",
              "version": "4fe815850bdc8d4cc94e06fe1de069424a895826",
              "versionType": "git"
            },
            {
              "lessThan": "4cd43a19900d0b98c1ec4bb6984763369d2e19ec",
              "status": "affected",
              "version": "4fe815850bdc8d4cc94e06fe1de069424a895826",
              "versionType": "git"
            },
            {
              "lessThan": "c23ae5091a8b3e50fe755257df020907e7c029bb",
              "status": "affected",
              "version": "4fe815850bdc8d4cc94e06fe1de069424a895826",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c",
            "drivers/net/ethernet/intel/ixgbe/ixgbe_main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.16"
            },
            {
              "lessThan": "5.16",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.29",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.2.*",
              "status": "unaffected",
              "version": "6.2.16",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.3.*",
              "status": "unaffected",
              "version": "6.3.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.4",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.29",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.2.16",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.3.3",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.4",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nixgbe: Fix panic during XDP_TX with \u003e 64 CPUs\n\nCommit 4fe815850bdc (\"ixgbe: let the xdpdrv work with more than 64 cpus\")\nadds support to allow XDP programs to run on systems with more than\n64 CPUs by locking the XDP TX rings and indexing them using cpu % 64\n(IXGBE_MAX_XDP_QS).\n\nUpon trying this out patch on a system with more than 64 cores,\nthe kernel paniced with an array-index-out-of-bounds at the return in\nixgbe_determine_xdp_ring in ixgbe.h, which means ixgbe_determine_xdp_q_idx\nwas just returning the cpu instead of cpu % IXGBE_MAX_XDP_QS.  An example\nsplat:\n\n ==========================================================================\n UBSAN: array-index-out-of-bounds in\n /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26\n index 65 is out of range for type \u0027ixgbe_ring *[64]\u0027\n ==========================================================================\n BUG: kernel NULL pointer dereference, address: 0000000000000058\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP NOPTI\n CPU: 65 PID: 408 Comm: ksoftirqd/65\n Tainted: G          IOE     5.15.0-48-generic #54~20.04.1-Ubuntu\n Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020\n RIP: 0010:ixgbe_xmit_xdp_ring+0x1b/0x1c0 [ixgbe]\n Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9\n 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 \u003c44\u003e 0f b7\n 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0\n RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282\n RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000\n RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000\n RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001\n R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000\n R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c\n FS:  0000000000000000(0000) GS:ffff92b9dfc00000(0000)\n knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  \u003cTASK\u003e\n  ixgbe_poll+0x103e/0x1280 [ixgbe]\n  ? sched_clock_cpu+0x12/0xe0\n  __napi_poll+0x30/0x160\n  net_rx_action+0x11c/0x270\n  __do_softirq+0xda/0x2ee\n  run_ksoftirqd+0x2f/0x50\n  smpboot_thread_fn+0xb7/0x150\n  ? sort_range+0x30/0x30\n  kthread+0x127/0x150\n  ? set_kthread_struct+0x50/0x50\n  ret_from_fork+0x1f/0x30\n  \u003c/TASK\u003e\n\nI think this is how it happens:\n\nUpon loading the first XDP program on a system with more than 64 CPUs,\nixgbe_xdp_locking_key is incremented in ixgbe_xdp_setup.  However,\nimmediately after this, the rings are reconfigured by ixgbe_setup_tc.\nixgbe_setup_tc calls ixgbe_clear_interrupt_scheme which calls\nixgbe_free_q_vectors which calls ixgbe_free_q_vector in a loop.\nixgbe_free_q_vector decrements ixgbe_xdp_locking_key once per call if\nit is non-zero.  Commenting out the decrement in ixgbe_free_q_vector\nstopped my system from panicing.\n\nI suspect to make the original patch work, I would need to load an XDP\nprogram and then replace it in order to get ixgbe_xdp_locking_key back\nabove 0 since ixgbe_setup_tc is only called when transitioning between\nXDP and non-XDP ring configurations, while ixgbe_xdp_locking_key is\nincremented every time ixgbe_xdp_setup is called.\n\nAlso, ixgbe_setup_tc can be called via ethtool --set-channels, so this\nbecomes another path to decrement ixgbe_xdp_locking_key to 0 on systems\nwith more than 64 CPUs.\n\nSince ixgbe_xdp_locking_key only protects the XDP_TX path and is tied\nto the number of CPUs present, there is no reason to disable it upon\nunloading an XDP program.  To avoid confusion, I have moved enabling\nixgbe_xdp_locking_key into ixgbe_sw_init, which is part of the probe path."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The out-of-bounds index is taken in ixgbe_run_xdp(), invoked per received packet from the ixgbe RX NAPI path, so a remote attacker triggers it purely by sending network traffic to the interface. ixgbe is a mainstream 10GbE datacenter NIC and XDP_TX deployments (L4 load balancers, DDoS scrubbers) are internet-facing.\nAC:L - Once an XDP program is attached the locking key is unconditionally zeroed on the first load, making the vulnerable state guaranteed rather than racy, and any traffic processed on a CPU index above 63 hits the OOB read deterministically. An attacker spraying source ports steers flows across RSS queues to reach high-numbered CPUs at will.\nPR:N - No credentials or local access are needed \u2014 the attacker only sends packets to the NIC, and the XDP program attachment is pre-existing deployment configuration rather than an attacker step. The vulnerable code runs in softirq before any authentication or socket-level access control.\nUI:N - No victim action is required at attack time; received packets are processed automatically by the driver\u0027s NAPI poll loop. The XDP program is already loaded as part of the system\u0027s normal operation.\nS:U - The out-of-bounds access, type confusion and ring corruption are all confined to kernel memory managed by the same security authority. No VM, IOMMU or sandbox boundary is crossed.\nC:H - Indices 69-127 resolve to live tx_ring[] pointers, and unsynchronized concurrent descriptor writes produce entries with an address from one producer and a length from the other, causing the NIC to DMA and transmit arbitrary kernel memory onto the wire where the remote attacker receives it. Index 64 additionally reinterprets the af_xdp_zc_qps bitmap as a ring, yielding wild pointer reads.\nI:H - Injecting XDP frames into a production TX ring without tx_lock or the netdev queue lock corrupts descriptors and tx_buffer_info concurrently with the normal transmit path, and ixgbe_clean_tx_irq() then passes an xdp_frame pointer to napi_consume_skb() because ring_is_xdp() is false. That type-confused free interprets a page-pool page as struct sk_buff \u2014 including calling skb-\u003edestructor read from groomable page contents \u2014 giving heap corruption and a control-flow hijack primitive.\nA:H - The reported and reproduced symptom is a kernel panic \u2014 a NULL pointer dereference in ixgbe_xmit_xdp_ring() from the UBSAN-flagged array-index-out-of-bounds, as shown in the commit\u0027s oops trace. Ring and heap corruption on the other index ranges likewise crash the system."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T09:17:08.999Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/1924450175349e64f8dfc3689efcb653dba0418e"
        },
        {
          "url": "https://git.kernel.org/stable/c/785b2b5b47b1aa4c31862948b312ea845401c5ec"
        },
        {
          "url": "https://git.kernel.org/stable/c/4cd43a19900d0b98c1ec4bb6984763369d2e19ec"
        },
        {
          "url": "https://git.kernel.org/stable/c/c23ae5091a8b3e50fe755257df020907e7c029bb"
        }
      ],
      "title": "ixgbe: Fix panic during XDP_TX with \u003e 64 CPUs",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-54090",
    "datePublished": "2025-12-24T13:06:19.666Z",
    "dateReserved": "2025-12-24T13:02:52.516Z",
    "dateUpdated": "2026-08-05T09:17:08.999Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2023-54090",
      "date": "2026-09-15",
      "epss": "0.0057",
      "percentile": "0.4548"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-54090\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-12-24T13:16:10.867\",\"lastModified\":\"2026-08-04T10:19:28.463\",\"vulnStatus\":\"Deferred\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nixgbe: Fix panic during XDP_TX with \u003e 64 CPUs\\n\\nCommit 4fe815850bdc (\\\"ixgbe: let the xdpdrv work with more than 64 cpus\\\")\\nadds support to allow XDP programs to run on systems with more than\\n64 CPUs by locking the XDP TX rings and indexing them using cpu % 64\\n(IXGBE_MAX_XDP_QS).\\n\\nUpon trying this out patch on a system with more than 64 cores,\\nthe kernel paniced with an array-index-out-of-bounds at the return in\\nixgbe_determine_xdp_ring in ixgbe.h, which means ixgbe_determine_xdp_q_idx\\nwas just returning the cpu instead of cpu % IXGBE_MAX_XDP_QS.  An example\\nsplat:\\n\\n ==========================================================================\\n UBSAN: array-index-out-of-bounds in\\n /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26\\n index 65 is out of range for type \u0027ixgbe_ring *[64]\u0027\\n ==========================================================================\\n BUG: kernel NULL pointer dereference, address: 0000000000000058\\n #PF: supervisor read access in kernel mode\\n #PF: error_code(0x0000) - not-present page\\n PGD 0 P4D 0\\n Oops: 0000 [#1] SMP NOPTI\\n CPU: 65 PID: 408 Comm: ksoftirqd/65\\n Tainted: G          IOE     5.15.0-48-generic #54~20.04.1-Ubuntu\\n Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020\\n RIP: 0010:ixgbe_xmit_xdp_ring+0x1b/0x1c0 [ixgbe]\\n Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9\\n 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 \u003c44\u003e 0f b7\\n 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0\\n RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282\\n RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000\\n RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000\\n RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001\\n R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000\\n R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c\\n FS:  0000000000000000(0000) GS:ffff92b9dfc00000(0000)\\n knlGS:0000000000000000\\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\n CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0\\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\\n PKRU: 55555554\\n Call Trace:\\n  \u003cTASK\u003e\\n  ixgbe_poll+0x103e/0x1280 [ixgbe]\\n  ? sched_clock_cpu+0x12/0xe0\\n  __napi_poll+0x30/0x160\\n  net_rx_action+0x11c/0x270\\n  __do_softirq+0xda/0x2ee\\n  run_ksoftirqd+0x2f/0x50\\n  smpboot_thread_fn+0xb7/0x150\\n  ? sort_range+0x30/0x30\\n  kthread+0x127/0x150\\n  ? set_kthread_struct+0x50/0x50\\n  ret_from_fork+0x1f/0x30\\n  \u003c/TASK\u003e\\n\\nI think this is how it happens:\\n\\nUpon loading the first XDP program on a system with more than 64 CPUs,\\nixgbe_xdp_locking_key is incremented in ixgbe_xdp_setup.  However,\\nimmediately after this, the rings are reconfigured by ixgbe_setup_tc.\\nixgbe_setup_tc calls ixgbe_clear_interrupt_scheme which calls\\nixgbe_free_q_vectors which calls ixgbe_free_q_vector in a loop.\\nixgbe_free_q_vector decrements ixgbe_xdp_locking_key once per call if\\nit is non-zero.  Commenting out the decrement in ixgbe_free_q_vector\\nstopped my system from panicing.\\n\\nI suspect to make the original patch work, I would need to load an XDP\\nprogram and then replace it in order to get ixgbe_xdp_locking_key back\\nabove 0 since ixgbe_setup_tc is only called when transitioning between\\nXDP and non-XDP ring configurations, while ixgbe_xdp_locking_key is\\nincremented every time ixgbe_xdp_setup is called.\\n\\nAlso, ixgbe_setup_tc can be called via ethtool --set-channels, so this\\nbecomes another path to decrement ixgbe_xdp_locking_key to 0 on systems\\nwith more than 64 CPUs.\\n\\nSince ixgbe_xdp_locking_key only protects the XDP_TX path and is tied\\nto the number of CPUs present, there is no reason to disable it upon\\nunloading an XDP program.  To avoid confusion, I have moved enabling\\nixgbe_xdp_locking_key into ixgbe_sw_init, which is part of the probe path.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c\",\"drivers/net/ethernet/intel/ixgbe/ixgbe_main.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4fe815850bdc8d4cc94e06fe1de069424a895826\",\"lessThan\":\"1924450175349e64f8dfc3689efcb653dba0418e\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4fe815850bdc8d4cc94e06fe1de069424a895826\",\"lessThan\":\"785b2b5b47b1aa4c31862948b312ea845401c5ec\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4fe815850bdc8d4cc94e06fe1de069424a895826\",\"lessThan\":\"4cd43a19900d0b98c1ec4bb6984763369d2e19ec\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4fe815850bdc8d4cc94e06fe1de069424a895826\",\"lessThan\":\"c23ae5091a8b3e50fe755257df020907e7c029bb\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c\",\"drivers/net/ethernet/intel/ixgbe/ixgbe_main.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5.16\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"5.16\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.29\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.2.16\",\"lessThanOrEqual\":\"6.2.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.3.3\",\"lessThanOrEqual\":\"6.3.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.4\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":9.8,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":5.9}]},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1924450175349e64f8dfc3689efcb653dba0418e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/4cd43a19900d0b98c1ec4bb6984763369d2e19ec\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/785b2b5b47b1aa4c31862948b312ea845401c5ec\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c23ae5091a8b3e50fe755257df020907e7c029bb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}",
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2026-08-04T22:54:08+00:00",
      "cve": "CVE-2023-54090",
      "id": "CVE-2023-54090",
      "initial_release_date": "2023-01-01T00:00:00+00:00",
      "product_status:fixed": "399",
      "product_status:known_affected": "38",
      "product_status:known_not_affected": "118",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: ixgbe: Fix panic during XDP_TX with \u003e 64 CPUs",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-54090.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-06T17:04:18Z",
      "cve": "CVE-2023-54090",
      "id": "CVE-2023-54090",
      "initial_release_date": "2025-12-25T00:55:52Z",
      "product_status:known_affected": "354",
      "product_status:known_not_affected": "432",
      "product_status:recommended": "245",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2023-54090",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-54090.json",
      "version": "23"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.