linux-stable.git/drivers/net/ethernet/intel, branch linux-6.16.y

i40e: improve VF MAC filters accounting

2025-10-02T11:48:35+00:00

commit b99dd77076bd3fddac6f7f1cbfa081c38fde17f5 upstream.

When adding new VM MAC, driver checks only *active* filters in
vsi->mac_filter_hash. Each MAC, even in non-active state is using resources.

To determine number of MACs VM uses, count VSI filters in *any* state.

Add i40e_count_all_filters() to simply count all filters, and rename
i40e_count_filters() to i40e_count_active_filters() to avoid ambiguity.

Fixes: cfb1d572c986 ("i40e: Add ensurance of MacVlan resources for every trusted VF")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: add mask to apply valid bits for itr_idx

2025-10-02T11:48:35+00:00

commit eac04428abe9f9cb203ffae4600791ea1d24eb18 upstream.

The ITR index (itr_idx) is only 2 bits wide. When constructing the
register value for QINT_RQCTL, all fields are ORed together. Without
masking, higher bits from itr_idx may overwrite adjacent fields in the
register.

Apply I40E_QINT_RQCTL_ITR_INDX_MASK to ensure only the intended bits are
set.

Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: add max boundary check for VF filters

2025-10-02T11:48:35+00:00

commit cb79fa7118c150c3c76a327894bb2eb878c02619 upstream.

There is no check for max filters that VF can request. Add it.

Fixes: e284fc280473 ("i40e: Add and delete cloud filter")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: fix validation of VF state in get resources

2025-10-02T11:48:35+00:00

commit 877b7e6ffc23766448236e8732254534c518ba42 upstream.

VF state I40E_VF_STATE_ACTIVE is not the only state in which
VF is actually active so it should not be used to determine
if a VF is allowed to obtain resources.

Use I40E_VF_STATE_RESOURCES_LOADED that is set only in
i40e_vc_get_vf_resources_msg() and cleared during reset.

Fixes: 61125b8be85d ("i40e: Fix failed opcode appearing if handling messages from VF")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: fix input validation logic for action_meta

2025-10-02T11:48:35+00:00

commit 9739d5830497812b0bdeaee356ddefbe60830b88 upstream.

Fix condition to check 'greater or equal' to prevent OOB dereference.

Fixes: e284fc280473 ("i40e: Add and delete cloud filter")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: fix idx validation in config queues msg

2025-10-02T11:48:35+00:00

commit f1ad24c5abe1eaef69158bac1405a74b3c365115 upstream.

Ensure idx is within range of active/initialized TCs when iterating over
vf->ch[idx] in i40e_vc_config_queues_msg().

Fixes: c27eac48160d ("i40e: Enable ADq and create queue channel/s on VF")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Kamakshi Nellore  (A Contingent Worker at Intel)
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: fix idx validation in i40e_validate_queue_map

2025-10-02T11:48:35+00:00

commit aa68d3c3ac8d1dcec40d52ae27e39f6d32207009 upstream.

Ensure idx is within range of active/initialized TCs when iterating over
vf->ch[idx] in i40e_validate_queue_map().

Fixes: c27eac48160d ("i40e: Enable ADq and create queue channel/s on VF")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Kamakshi Nellore  (A Contingent Worker at Intel)
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: add validation for ring_len param

2025-10-02T11:48:35+00:00

commit 55d225670def06b01af2e7a5e0446fbe946289e8 upstream.

The `ring_len` parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.

To address this, introduce an upper boundary check for both Tx and Rx
queue lengths. The maximum number of descriptors supported by the
hardware is 8k-32.
Additionally, enforce alignment constraints: Tx rings must be a multiple
of 8, and Rx rings must be a multiple of 32.

Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface")
Cc: stable@vger.kernel.org
Signed-off-by: Lukasz Czapnik 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

igc: don't fail igc_probe() on LED setup error

2025-09-25T09:16:44+00:00

[ Upstream commit 528eb4e19ec0df30d0c9ae4074ce945667dde919 ]

When igc_led_setup() fails, igc_probe() fails and triggers kernel panic
in free_netdev() since unregister_netdev() is not called. [1]
This behavior can be tested using fault-injection framework, especially
the failslab feature. [2]

Since LED support is not mandatory, treat LED setup failures as
non-fatal and continue probe with a warning message, consequently
avoiding the kernel panic.

[1]
 kernel BUG at net/core/dev.c:12047!
 Oops: invalid opcode: 0000 [#1] SMP NOPTI
 CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary)
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
 RIP: 0010:free_netdev+0x278/0x2b0
 [...]
 Call Trace:
  
  igc_probe+0x370/0x910
  local_pci_probe+0x3a/0x80
  pci_device_probe+0xd1/0x200
 [...]

[2]
 #!/bin/bash -ex

 FAILSLAB_PATH=/sys/kernel/debug/failslab/
 DEVICE=0000:00:05.0
 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \
         | awk '{printf("0x%s", $1)}')
 END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100)))

 echo $START_ADDR > $FAILSLAB_PATH/require-start
 echo $END_ADDR > $FAILSLAB_PATH/require-end
 echo 1 > $FAILSLAB_PATH/times
 echo 100 > $FAILSLAB_PATH/probability
 echo N > $FAILSLAB_PATH/ignore-gfp-wait

 echo $DEVICE > /sys/bus/pci/drivers/igc/bind

Fixes: ea578703b03d ("igc: Add support for LEDs on i225/i226")
Signed-off-by: Kohei Enju 
Reviewed-by: Paul Menzel 
Reviewed-by: Aleksandr Loktionov 
Reviewed-by: Vitaly Lifshits 
Reviewed-by: Kurt Kanzenbach 
Tested-by: Mor Bar-Gabay 
Signed-off-by: Tony Nguyen 
Signed-off-by: Sasha Levin

ixgbe: destroy aci.lock later within ixgbe_remove path

2025-09-25T09:16:44+00:00

[ Upstream commit 316ba68175b04a9f6f75295764789ea94e31d48c ]

There's another issue with aci.lock and previous patch uncovers it.
aci.lock is being destroyed during removing ixgbe while some of the
ixgbe closing routines are still ongoing. These routines use Admin
Command Interface which require taking aci.lock which has been already
destroyed what leads to call trace.

[  +0.000004] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[  +0.000007] WARNING: CPU: 12 PID: 10277 at kernel/locking/mutex.c:155 mutex_lock+0x5f/0x70
[  +0.000002] Call Trace:
[  +0.000003]  
[  +0.000006]  ixgbe_aci_send_cmd+0xc8/0x220 [ixgbe]
[  +0.000049]  ? try_to_wake_up+0x29d/0x5d0
[  +0.000009]  ixgbe_disable_rx_e610+0xc4/0x110 [ixgbe]
[  +0.000032]  ixgbe_disable_rx+0x3d/0x200 [ixgbe]
[  +0.000027]  ixgbe_down+0x102/0x3b0 [ixgbe]
[  +0.000031]  ixgbe_close_suspend+0x28/0x90 [ixgbe]
[  +0.000028]  ixgbe_close+0xfb/0x100 [ixgbe]
[  +0.000025]  __dev_close_many+0xae/0x220
[  +0.000005]  dev_close_many+0xc2/0x1a0
[  +0.000004]  ? kernfs_should_drain_open_files+0x2a/0x40
[  +0.000005]  unregister_netdevice_many_notify+0x204/0xb00
[  +0.000006]  ? __kernfs_remove.part.0+0x109/0x210
[  +0.000006]  ? kobj_kset_leave+0x4b/0x70
[  +0.000008]  unregister_netdevice_queue+0xf6/0x130
[  +0.000006]  unregister_netdev+0x1c/0x40
[  +0.000005]  ixgbe_remove+0x216/0x290 [ixgbe]
[  +0.000021]  pci_device_remove+0x42/0xb0
[  +0.000007]  device_release_driver_internal+0x19c/0x200
[  +0.000008]  driver_detach+0x48/0x90
[  +0.000003]  bus_remove_driver+0x6d/0xf0
[  +0.000006]  pci_unregister_driver+0x2e/0xb0
[  +0.000005]  ixgbe_exit_module+0x1c/0xc80 [ixgbe]

Same as for the previous commit, the issue has been highlighted by the
commit 337369f8ce9e ("locking/mutex: Add MUTEX_WARN_ON() into fast path").

Move destroying aci.lock to the end of ixgbe_remove(), as this
simply fixes the issue.

Fixes: 4600cdf9f5ac ("ixgbe: Enable link management in E610 device")
Signed-off-by: Jedrzej Jagielski 
Reviewed-by: Przemek Kitszel 
Reviewed-by: Aleksandr Loktionov 
Reviewed-by: Simon Horman 
Tested-by: Rinitha S  (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen 
Signed-off-by: Sasha Levin