ice: fix NULL pointer dereference in ice_reset_all_vfs()

In the Linux kernel, the following vulnerability has been resolved:

ice: fix NULL pointer dereference in ice_reset_all_vfs()

ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi().

When the VSI rebuild fails (e.g. during NVM firmware update via

nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path,

leaving txq_map and rxq_map as NULL. The subsequent unconditional call

to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in

ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0].

The single-VF reset path in ice_reset_vf() already handles this

correctly by checking the return value of ice_vf_reconfig_vsi() and

skipping ice_vf_post_vsi_rebuild() on failure.

Apply the same pattern to ice_reset_all_vfs(): check the return value

of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and

ice_eswitch_attach_vf() on failure. The VF is left safely disabled

(ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can

be recovered via a VFLR triggered by a PCI reset of the VF

(sysfs reset or driver rebind).

Note that this patch does not prevent the VF VSI rebuild from failing

during NVM update — the underlying cause is firmware being in a

transitional state while the EMP reset is processed, which can cause

Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This

patch only prevents the subsequent NULL pointer dereference that

crashes the kernel when the rebuild does fail.

crash> bt

PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5"

#0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee

#1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba

#2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540

#3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda

#4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997

#5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595

#6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2

[exception RIP: ice_ena_vf_q_mappings+0x79]

RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206

RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000

RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000

RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040

R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000

R13: 0000000000000010 R14: R15:

ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

#7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice]

#8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice]

#9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice]

#10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4

#11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de

#12 [ff72159bcfe5bf18] kthread at ffffffffaa946663

#13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9

The panic occurs attempting to dereference the NULL pointer in RDX at

ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi).

The faulting VSI is an allocated slab object but not fully initialized

after a failed ice_vsi_rebuild():

crash> struct ice_vsi 0xff34c9efc27d4828

netdev = 0x0,

rx_rings = 0x0,

tx_rings = 0x0,

q_vectors = 0x0,

txq_map = 0x0,

rxq_map = 0x0,

alloc_txq = 0x10,

num_txq = 0x10,

alloc_rxq = 0x10,

num_rxq = 0x10,

The nvmupdate64e process was performing NVM firmware update:

crash> bt 0xff34c9edd1a30000

PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e"

#0 [ff72159bcd617618] __schedule at ffffffffab5333f8

#4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice]

#5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice]

#6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice]

#7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice]

#8

---truncated---