net: hisilicon: KASAN null-ptr-deref from uninitialized NAPI on early IRQ

[Jaeyoung Chung]

Hi,

hip04_mac_probe() in drivers/net/ethernet/hisilicon/hip04_eth.c and
hix5hd2_dev_probe() in drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
register the interrupt handler with devm_request_irq() before they
initialize priv->napi with netif_napi_add(). If an interrupt arrives
before netif_napi_add(), the handler schedules an uninitialized NAPI,
causing a kernel panic.

The probe path, in hip04_mac_probe():

    ndev = alloc_etherdev(sizeof(struct hip04_priv)); /* priv->napi zeroed */
    ...
    ret = devm_request_irq(d, irq, hip04_mac_interrupt,
                           0, pdev->name, ndev);       /* register handler */
    ...
    netif_napi_add(ndev, &priv->napi, hip04_rx_poll);  /* init priv->napi */

hix5hd2_dev_probe() has the same ordering: devm_request_irq() registers
hix5hd2_interrupt() before netif_napi_add() initializes priv->napi.

The interrupt handlers, hip04_mac_interrupt() and hix5hd2_interrupt(),
schedule priv->napi via __napi_schedule().

Because priv->napi is still zeroed, it is marked scheduled and queued
on the poll list; when NET_RX_SOFTIRQ runs, __napi_poll() calls
->poll(), which netif_napi_add() has not assigned yet.

If the device raises an interrupt after devm_request_irq() and before
netif_napi_add(), the handler schedules priv->napi while its ->poll() is
still NULL. As a result, net_rx_action() dereferences the NULL ->poll()
in softirq context, triggering a KASAN null-ptr-deref.

Suggested fix: move devm_request_irq() below netif_napi_add(), so
priv->napi is initialized before the handler can run.

Reported-by: Sangyun Kim <sangyun.kim@xxxxxxxxx>
Reported-by: Kyungwook Boo <bookyungwook@xxxxxxxxx>

Thanks,
Jaeyoung Chung