ghsa-g2fc-vv42-p4pc
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup
The ixgbe driver currently generates a NULL pointer dereference with some machine (online cpus < 63). This is due to the fact that the maximum value of num_xdp_queues is nr_cpu_ids. Code is in "ixgbe_set_rss_queues"".
Here's how the problem repeats itself: Some machine (online cpus < 63), And user set num_queues to 63 through ethtool. Code is in the "ixgbe_set_channels", adapter->ring_feature[RING_F_FDIR].limit = count;
It becomes 63.
When user use xdp, "ixgbe_set_rss_queues" will set queues num. adapter->num_rx_queues = rss_i; adapter->num_tx_queues = rss_i; adapter->num_xdp_queues = ixgbe_xdp_queues(adapter);
And rss_i's value is from f = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit;
So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup", for (i = 0; i < adapter->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem)
It leads to panic.
Call trace: [exception RIP: ixgbe_xdp+368] RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90 RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000 R10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000 R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235 10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384 11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd 12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb 13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88 14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319 15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290 16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8 17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64 18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9 19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c
So I fix ixgbe_max_channels so that it will not allow a setting of queues to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup, take the smaller value of num_rx_queues and num_xdp_queues.
{
"affected": [],
"aliases": [
"CVE-2021-47399"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup\n\nThe ixgbe driver currently generates a NULL pointer dereference with\nsome machine (online cpus \u003c 63). This is due to the fact that the\nmaximum value of num_xdp_queues is nr_cpu_ids. Code is in\n\"ixgbe_set_rss_queues\"\".\n\nHere\u0027s how the problem repeats itself:\nSome machine (online cpus \u003c 63), And user set num_queues to 63 through\nethtool. Code is in the \"ixgbe_set_channels\",\n\tadapter-\u003ering_feature[RING_F_FDIR].limit = count;\n\nIt becomes 63.\n\nWhen user use xdp, \"ixgbe_set_rss_queues\" will set queues num.\n\tadapter-\u003enum_rx_queues = rss_i;\n\tadapter-\u003enum_tx_queues = rss_i;\n\tadapter-\u003enum_xdp_queues = ixgbe_xdp_queues(adapter);\n\nAnd rss_i\u0027s value is from\n\tf = \u0026adapter-\u003ering_feature[RING_F_FDIR];\n\trss_i = f-\u003eindices = f-\u003elimit;\n\nSo \"num_rx_queues\" \u003e \"num_xdp_queues\", when run to \"ixgbe_xdp_setup\",\n\tfor (i = 0; i \u003c adapter-\u003enum_rx_queues; i++)\n\t\tif (adapter-\u003exdp_ring[i]-\u003exsk_umem)\n\nIt leads to panic.\n\nCall trace:\n[exception RIP: ixgbe_xdp+368]\nRIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297\nRAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90\nRBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000\nR10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000\nR13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530\nORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc\n 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808\n 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235\n10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384\n11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd\n12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb\n13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88\n14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319\n15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290\n16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8\n17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64\n18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9\n19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c\n\nSo I fix ixgbe_max_channels so that it will not allow a setting of queues\nto be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,\ntake the smaller value of num_rx_queues and num_xdp_queues.",
"id": "GHSA-g2fc-vv42-p4pc",
"modified": "2024-12-24T18:30:48Z",
"published": "2024-05-21T15:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47399"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20f6c4a31a525edd9ea6243712b868ba0e4e331e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2744341dd52e935344ca1b4bf189ba0d182a3e8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/513e605d7a9ce136886cb42ebb2c40e9a6eb6333"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.