CVE-2023-54070 (GCVE-0-2023-54070)
Vulnerability from cvelistv5
Published
2025-12-24 12:23
Modified
2025-12-24 12:23
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
igb: clean up in all error paths when enabling SR-IOV
After commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removing
the igb module could hang or crash (depending on the machine) when the
module has been loaded with the max_vfs parameter set to some value != 0.
In case of one test machine with a dual port 82580, this hang occurred:
[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1
[ 233.093257] igb 0000:41:00.1: IOV Disabled
[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0
[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)
[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000
[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)
[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c
[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)
[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000
[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)
[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c
[ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback)
[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0
[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed
[ 234.157244] igb 0000:41:00.0: IOV Disabled
[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.
[ 371.627489] Not tainted 6.4.0-dirty #2
[ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this.
[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0
[ 371.650330] Call Trace:
[ 371.653061] <TASK>
[ 371.655407] __schedule+0x20e/0x660
[ 371.659313] schedule+0x5a/0xd0
[ 371.662824] schedule_preempt_disabled+0x11/0x20
[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0
[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10
[ 371.678105] report_error_detected+0x25/0x1c0
[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10
[ 371.688618] pci_walk_bus+0x72/0x90
[ 371.692519] pcie_do_recovery+0xb2/0x330
[ 371.696899] aer_process_err_devices+0x117/0x170
[ 371.702055] aer_isr+0x1c0/0x1e0
[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0
[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10
[ 371.715496] irq_thread_fn+0x20/0x60
[ 371.719491] irq_thread+0xe6/0x1b0
[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10
[ 371.728255] ? __pfx_irq_thread+0x10/0x10
[ 371.732731] kthread+0xe2/0x110
[ 371.736243] ? __pfx_kthread+0x10/0x10
[ 371.740430] ret_from_fork+0x2c/0x50
[ 371.744428] </TASK>
The reproducer was a simple script:
#!/bin/sh
for i in `seq 1 5`; do
modprobe -rv igb
modprobe -v igb max_vfs=1
sleep 1
modprobe -rv igb
done
It turned out that this could only be reproduce on 82580 (quad and
dual-port), but not on 82576, i350 and i210. Further debugging showed
that igb_enable_sriov()'s call to pci_enable_sriov() is failing, because
dev->is_physfn is 0 on 82580.
Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),
igb_enable_sriov() jumped into the "err_out" cleanup branch. After this
commit it only returned the error code.
So the cleanup didn't take place, and the incorrect VF setup in the
igb_adapter structure fooled the igb driver into assuming that VFs have
been set up where no VF actually existed.
Fix this problem by cleaning up again if pci_enable_sriov() fails.
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/igb/igb_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0e3ea7e82a06014b9baf1b84ba579c38cbff3558",
"status": "affected",
"version": "50f303496d92e25b79bdfb73e3707ad0684ad67f",
"versionType": "git"
},
{
"lessThan": "bc6ed2fa24b14e40e1005488bbe11268ce7108fa",
"status": "affected",
"version": "50f303496d92e25b79bdfb73e3707ad0684ad67f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/igb/igb_main.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.3"
},
{
"lessThan": "6.3",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.4",
"versionStartIncluding": "6.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6",
"versionStartIncluding": "6.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: clean up in all error paths when enabling SR-IOV\n\nAfter commit 50f303496d92 (\"igb: Enable SR-IOV after reinit\"), removing\nthe igb module could hang or crash (depending on the machine) when the\nmodule has been loaded with the max_vfs parameter set to some value != 0.\n\nIn case of one test machine with a dual port 82580, this hang occurred:\n\n[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1\n[ 233.093257] igb 0000:41:00.1: IOV Disabled\n[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0\n[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)\n[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000\n[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)\n[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c\n[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)\n[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000\n[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)\n[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c\n[ 233.538214] pci 0000:41:00.1: AER: can\u0027t recover (no error_detected callback)\n[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0\n[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed\n[ 234.157244] igb 0000:41:00.0: IOV Disabled\n[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.\n[ 371.627489] Not tainted 6.4.0-dirty #2\n[ 371.632257] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this.\n[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0\n[ 371.650330] Call Trace:\n[ 371.653061] \u003cTASK\u003e\n[ 371.655407] __schedule+0x20e/0x660\n[ 371.659313] schedule+0x5a/0xd0\n[ 371.662824] schedule_preempt_disabled+0x11/0x20\n[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0\n[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10\n[ 371.678105] report_error_detected+0x25/0x1c0\n[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10\n[ 371.688618] pci_walk_bus+0x72/0x90\n[ 371.692519] pcie_do_recovery+0xb2/0x330\n[ 371.696899] aer_process_err_devices+0x117/0x170\n[ 371.702055] aer_isr+0x1c0/0x1e0\n[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0\n[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10\n[ 371.715496] irq_thread_fn+0x20/0x60\n[ 371.719491] irq_thread+0xe6/0x1b0\n[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10\n[ 371.728255] ? __pfx_irq_thread+0x10/0x10\n[ 371.732731] kthread+0xe2/0x110\n[ 371.736243] ? __pfx_kthread+0x10/0x10\n[ 371.740430] ret_from_fork+0x2c/0x50\n[ 371.744428] \u003c/TASK\u003e\n\nThe reproducer was a simple script:\n\n #!/bin/sh\n for i in `seq 1 5`; do\n modprobe -rv igb\n modprobe -v igb max_vfs=1\n sleep 1\n modprobe -rv igb\n done\n\nIt turned out that this could only be reproduce on 82580 (quad and\ndual-port), but not on 82576, i350 and i210. Further debugging showed\nthat igb_enable_sriov()\u0027s call to pci_enable_sriov() is failing, because\ndev-\u003eis_physfn is 0 on 82580.\n\nPrior to commit 50f303496d92 (\"igb: Enable SR-IOV after reinit\"),\nigb_enable_sriov() jumped into the \"err_out\" cleanup branch. After this\ncommit it only returned the error code.\n\nSo the cleanup didn\u0027t take place, and the incorrect VF setup in the\nigb_adapter structure fooled the igb driver into assuming that VFs have\nbeen set up where no VF actually existed.\n\nFix this problem by cleaning up again if pci_enable_sriov() fails."
}
],
"providerMetadata": {
"dateUpdated": "2025-12-24T12:23:14.182Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/0e3ea7e82a06014b9baf1b84ba579c38cbff3558"
},
{
"url": "https://git.kernel.org/stable/c/bc6ed2fa24b14e40e1005488bbe11268ce7108fa"
}
],
"title": "igb: clean up in all error paths when enabling SR-IOV",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-54070",
"datePublished": "2025-12-24T12:23:14.182Z",
"dateReserved": "2025-12-24T12:21:05.093Z",
"dateUpdated": "2025-12-24T12:23:14.182Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2023-54070\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-12-24T13:16:08.850\",\"lastModified\":\"2025-12-24T13:16:08.850\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nigb: clean up in all error paths when enabling SR-IOV\\n\\nAfter commit 50f303496d92 (\\\"igb: Enable SR-IOV after reinit\\\"), removing\\nthe igb module could hang or crash (depending on the machine) when the\\nmodule has been loaded with the max_vfs parameter set to some value != 0.\\n\\nIn case of one test machine with a dual port 82580, this hang occurred:\\n\\n[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1\\n[ 233.093257] igb 0000:41:00.1: IOV Disabled\\n[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0\\n[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)\\n[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000\\n[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)\\n[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c\\n[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)\\n[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000\\n[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)\\n[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c\\n[ 233.538214] pci 0000:41:00.1: AER: can\u0027t recover (no error_detected callback)\\n[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0\\n[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed\\n[ 234.157244] igb 0000:41:00.0: IOV Disabled\\n[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.\\n[ 371.627489] Not tainted 6.4.0-dirty #2\\n[ 371.632257] \\\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\\\" disables this.\\n[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0\\n[ 371.650330] Call Trace:\\n[ 371.653061] \u003cTASK\u003e\\n[ 371.655407] __schedule+0x20e/0x660\\n[ 371.659313] schedule+0x5a/0xd0\\n[ 371.662824] schedule_preempt_disabled+0x11/0x20\\n[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0\\n[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10\\n[ 371.678105] report_error_detected+0x25/0x1c0\\n[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10\\n[ 371.688618] pci_walk_bus+0x72/0x90\\n[ 371.692519] pcie_do_recovery+0xb2/0x330\\n[ 371.696899] aer_process_err_devices+0x117/0x170\\n[ 371.702055] aer_isr+0x1c0/0x1e0\\n[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0\\n[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10\\n[ 371.715496] irq_thread_fn+0x20/0x60\\n[ 371.719491] irq_thread+0xe6/0x1b0\\n[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10\\n[ 371.728255] ? __pfx_irq_thread+0x10/0x10\\n[ 371.732731] kthread+0xe2/0x110\\n[ 371.736243] ? __pfx_kthread+0x10/0x10\\n[ 371.740430] ret_from_fork+0x2c/0x50\\n[ 371.744428] \u003c/TASK\u003e\\n\\nThe reproducer was a simple script:\\n\\n #!/bin/sh\\n for i in `seq 1 5`; do\\n modprobe -rv igb\\n modprobe -v igb max_vfs=1\\n sleep 1\\n modprobe -rv igb\\n done\\n\\nIt turned out that this could only be reproduce on 82580 (quad and\\ndual-port), but not on 82576, i350 and i210. Further debugging showed\\nthat igb_enable_sriov()\u0027s call to pci_enable_sriov() is failing, because\\ndev-\u003eis_physfn is 0 on 82580.\\n\\nPrior to commit 50f303496d92 (\\\"igb: Enable SR-IOV after reinit\\\"),\\nigb_enable_sriov() jumped into the \\\"err_out\\\" cleanup branch. After this\\ncommit it only returned the error code.\\n\\nSo the cleanup didn\u0027t take place, and the incorrect VF setup in the\\nigb_adapter structure fooled the igb driver into assuming that VFs have\\nbeen set up where no VF actually existed.\\n\\nFix this problem by cleaning up again if pci_enable_sriov() fails.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0e3ea7e82a06014b9baf1b84ba579c38cbff3558\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/bc6ed2fa24b14e40e1005488bbe11268ce7108fa\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.
Loading…
Loading…