Re: [PATCH RFC] e1000e: reject non-PCIe devices and check reset_hw() return value

On Mon, Aug 17, 2026 at 12:53 AM 'syzbot' via
syzkaller-upstream-moderation
<[email protected]> wrote:
>
> When forcing the e1000e driver to bind to an incompatible non-PCIe device
> (such as the e1000 82540EM) via sysfs driver_override, a mismatch in
> hardware register layouts occurs. This causes the driver to blindly retry
> NVM reads and wait for a hardware response that never comes. When multiple
> threads attempt this concurrently, they serialize on the device lock, and
> the cumulative wait time easily exceeds the kernel's hung task timeout,
> leading to a system crash:
>
> INFO: task syz.2.41:7507 blocked for more than 143 seconds.
> ...
> Call Trace:
>  <TASK>
>  __schedule+0x17e7/0x5630 kernel/sched/core.c:7234
>  schedule+0x164/0x2b0 kernel/sched/core.c:7326
>  __mutex_lock_common kernel/locking/mutex.c:726 [inline]
>  __mutex_lock+0x7bf/0x1550 kernel/locking/mutex.c:821
>  device_lock include/linux/device.h:1104 [inline]
>  __device_driver_lock drivers/base/dd.c:1171 [inline]
>  device_driver_attach+0xd5/0x1d0 drivers/base/dd.c:1202
>  bind_store+0x1d0/0x220 drivers/base/bus.c:267
> ...
> NMI backtrace for cpu 1
> ...
> RIP: 0010:e1000e_poll_eerd_eewr_done
> drivers/net/ethernet/intel/e1000e/nvm.c:133 [inline]
> RIP: 0010:e1000e_read_nvm_eerd+0xdf/0x300
> drivers/net/ethernet/intel/e1000e/nvm.c:311
> ...
> Call Trace:
>  <TASK>
>  e1000_read_nvm drivers/net/ethernet/intel/e1000e/e1000.h:588 [inline]
>  e1000e_validate_nvm_checksum_generic+0xcb/0x3e0
>  drivers/net/ethernet/intel/e1000e/nvm.c:553
>  e1000_validate_nvm_checksum_82571+0x176/0x290
>  drivers/net/ethernet/intel/e1000e/82571.c:787
>  e1000_validate_nvm_checksum drivers/net/ethernet/intel/e1000e/e1000.h:577
>  [inline]
>  e1000_probe+0x12f8/0x2b20 drivers/net/ethernet/intel/e1000e/netdev.c:7590
>  local_pci_probe drivers/pci/pci-driver.c:332 [inline]
>  pci_call_probe drivers/pci/pci-driver.c:394 [inline]
>  __pci_device_probe drivers/pci/pci-driver.c:455 [inline]
>  pci_device_probe+0x431/0xc90 drivers/pci/pci-driver.c:489
>  call_driver_probe drivers/base/dd.c:-1 [inline]
>  really_probe+0x254/0xae0 drivers/base/dd.c:706
>  __driver_probe_device+0x1e8/0x360 drivers/base/dd.c:868
>  device_driver_attach+0xe0/0x1d0 drivers/base/dd.c:1203
>  bind_store+0x1d0/0x220 drivers/base/bus.c:267
>
> Fix this by adding an early sanity check in e1000_probe() to reject
> non-PCIe devices using pci_is_pcie(). Additionally, check the return value
> of adapter->hw.mac.ops.reset_hw() and abort the probe with -EIO if it
> fails. This prevents the driver from proceeding to the NVM checksum
> validation loop, which is responsible for the massive delay.
>
> Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)")
> Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot
> Reported-by: [email protected]
> Closes: https://syzkaller.appspot.com/bug?extid=8ce4dba751e79facdc38
> Link: https://syzkaller.appspot.com/ai_job?id=bf813674-8b64-4b49-ac67-92a88e64885d
> To: "Andrew Lunn" <[email protected]>
> To: "Tony Nguyen" <[email protected]>
> To: "David S. Miller" <[email protected]>
> To: "Eric Dumazet" <[email protected]>
> To: <[email protected]>
> To: "Jakub Kicinski" <[email protected]>
> To: <[email protected]>
> To: "Paolo Abeni" <[email protected]>
> To: "Przemek Kitszel" <[email protected]>
> To: "Auke Kok" <[email protected]>
> Cc: <[email protected]>
>
> ---
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 844f31ab3..6d087a414 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -7393,6 +7393,9 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>         int bars, i, err;
>         s32 ret_val = 0;
>
> +       if (!pci_is_pcie(pdev))
> +               return -ENODEV;

Is it really correct to enforce it must only be a pci device here?

> +
>         if (ei->flags2 & FLAG2_DISABLE_ASPM_L0S)
>                 aspm_disable_flag = PCIE_LINK_STATE_L0S;
>         if (ei->flags2 & FLAG2_DISABLE_ASPM_L1)
> @@ -7581,7 +7584,12 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>         /* before reading the NVM, reset the controller to
>          * put the device in a known good starting state
>          */
> -       adapter->hw.mac.ops.reset_hw(&adapter->hw);
> +       err = adapter->hw.mac.ops.reset_hw(&adapter->hw);
> +       if (err) {
> +               dev_err(&pdev->dev, "Hardware Error\n");
> +               err = -EIO;
> +               goto err_hw_init;
> +       }

Can we return an actual error here?

>
>         /* systems with ASPM and others may see the checksum fail on the first
>          * attempt. Let's give it a few tries
>
>
> base-commit: db2ddb87143519e20a95aa36c60b36107b736a58
> --
> This is an AI-generated patch subject to moderation.
> Reply with '#syz upstream' to Sign-off the patch as a human author
> and send it to the upstream kernel mailing lists.
> Reply with '#syz reject' to reject it ('#syz unreject' to undo).
>
> See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
> You can comment on the patch as usual, syzbot will try to address
> the comments and send a new version of the patch if necessary.
> syzbot engineers can be reached at [email protected].
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-upstream-moderation" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-upstream-moderation/c7465765-2009-4803-b5de-69a84efcdeb6%40mail.kernel.org.