CVE-2026-99200

What it actually does

Null pointer dereference during hisi_femac network driver probe when netdev_ops has not yet been assigned before phy_attach_direct is called under CONFIG_NET_SHAPER, resulting in kernel panic.

Why it matters to the business

Systems using affected Hisilicon network hardware experience immediate crash on driver initialization or boot, causing downtime and loss of network connectivity until patched kernels are deployed.

How an attack unfolds

An attacker with local access or ability to trigger driver loading on vulnerable hardware with the CONFIG_NET_SHAPER option enabled causes the probe sequence to dereference a null netdev_ops pointer, triggering a kernel panic and denial of service.

How to fix it

Update to a Linux kernel containing the fix that assigns netdev_ops before PHY connection in hisi_femac_drv_probe, matching the approach used in the emac driver.

How to confirm the fix worked

Inspect the hisi_femac driver source to confirm netdev_ops assignment precedes of_phy_get_and_connect and phy_attach_direct calls; test probe on hardware with CONFIG_NET_SHAPER enabled.

Typical attack path

1. Gain local access or control over hardware initialization on target system
2. Ensure CONFIG_NET_SHAPER is enabled in the running kernel
3. Trigger hisi_femac_drv_probe via device enumeration or module load
4. phy_attach_direct reads uninitialized netdev_ops causing NULL dereference and panic

How to detect it

Review kernel panic logs and dmesg for stack traces containing hisi_femac_drv_probe, phy_attach_direct, or phy_link_topo_add_phy; correlate with systems that have the hisi_femac driver and CONFIG_NET_SHAPER.

What your security team should do

• Prioritize kernel upgrade for any systems exposing hisi_femac hardware within the next maintenance window
• Audit boot logs for prior hisi_femac-related panics on affected configurations
• Disable CONFIG_NET_SHAPER temporarily if immediate patching is not feasible on critical devices