CVE-2023-54070

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: clean up in all error paths when enabling SR-IOV<br /> <br /> After commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removing<br /> the igb module could hang or crash (depending on the machine) when the<br /> module has been loaded with the max_vfs parameter set to some value != 0.<br /> <br /> In case of one test machine with a dual port 82580, this hang occurred:<br /> <br /> [ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1<br /> [ 233.093257] igb 0000:41:00.1: IOV Disabled<br /> [ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0<br /> [ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)<br /> [ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000<br /> [ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)<br /> [ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c<br /> [ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)<br /> [ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000<br /> [ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)<br /> [ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c<br /> [ 233.538214] pci 0000:41:00.1: AER: can&amp;#39;t recover (no error_detected callback)<br /> [ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0<br /> [ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed<br /> [ 234.157244] igb 0000:41:00.0: IOV Disabled<br /> [ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.<br /> [ 371.627489] Not tainted 6.4.0-dirty #2<br /> [ 371.632257] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this.<br /> [ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0<br /> [ 371.650330] Call Trace:<br /> [ 371.653061] <br /> [ 371.655407] __schedule+0x20e/0x660<br /> [ 371.659313] schedule+0x5a/0xd0<br /> [ 371.662824] schedule_preempt_disabled+0x11/0x20<br /> [ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0<br /> [ 371.673237] ? __pfx_aer_root_reset+0x10/0x10<br /> [ 371.678105] report_error_detected+0x25/0x1c0<br /> [ 371.682974] ? __pfx_report_normal_detected+0x10/0x10<br /> [ 371.688618] pci_walk_bus+0x72/0x90<br /> [ 371.692519] pcie_do_recovery+0xb2/0x330<br /> [ 371.696899] aer_process_err_devices+0x117/0x170<br /> [ 371.702055] aer_isr+0x1c0/0x1e0<br /> [ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0<br /> [ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10<br /> [ 371.715496] irq_thread_fn+0x20/0x60<br /> [ 371.719491] irq_thread+0xe6/0x1b0<br /> [ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10<br /> [ 371.728255] ? __pfx_irq_thread+0x10/0x10<br /> [ 371.732731] kthread+0xe2/0x110<br /> [ 371.736243] ? __pfx_kthread+0x10/0x10<br /> [ 371.740430] ret_from_fork+0x2c/0x50<br /> [ 371.744428] <br /> <br /> The reproducer was a simple script:<br /> <br /> #!/bin/sh<br /> for i in `seq 1 5`; do<br /> modprobe -rv igb<br /> modprobe -v igb max_vfs=1<br /> sleep 1<br /> modprobe -rv igb<br /> done<br /> <br /> It turned out that this could only be reproduce on 82580 (quad and<br /> dual-port), but not on 82576, i350 and i210. Further debugging showed<br /> that igb_enable_sriov()&amp;#39;s call to pci_enable_sriov() is failing, because<br /> dev-&gt;is_physfn is 0 on 82580.<br /> <br /> Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),<br /> igb_enable_sriov() jumped into the "err_out" cleanup branch. After this<br /> commit it only returned the error code.<br /> <br /> So the cleanup didn&amp;#39;t take place, and the incorrect VF setup in the<br /> igb_adapter structure fooled the igb driver into assuming that VFs have<br /> been set up where no VF actually existed.<br /> <br /> Fix this problem by cleaning up again if pci_enable_sriov() fails.