CVE-2022-48972

What it actually does

Missing INIT_LIST_HEAD initialization on wpan_dev list within ieee802154_if_add leads to null pointer dereference in cfg802154_netdev_notifier_call during netdevice registration and unregistration.

Why it matters to the business

Systems using affected Linux kernel IEEE 802.15.4 drivers may experience crashes or denial of service during hardware probe or device registration, increasing downtime risk for specialized wireless deployments.

How an attack unfolds

An attacker with local access or the ability to trigger hardware probe (such as mcr20a) causes ieee802154_register_hw to call ieee802154_if_add without list initialization; subsequent notifier chain during unregister triggers use-after-free style null dereference.

How to fix it

Apply the upstream fix that adds INIT_LIST_HEAD on the wpan_dev list inside ieee802154_if_add; for enalean/tuleap update to commit 16d9efccb2fad8e10343be2604e94c9058ef2c89 or later kernel containing the resolution.

How to confirm the fix worked

Confirm presence of INIT_LIST_HEAD call on wpan_dev in ieee802154_if_add source; re-run fault-injection tests targeting netdevice registration and verify absence of null-ptr-deref in cfg802154_netdev_notifier_call.

Typical attack path

1. Load or trigger probe of vulnerable IEEE 802.15.4 driver such as mcr20a
2. ieee802154_register_hw invokes ieee802154_if_add which allocates wpan_dev without INIT_LIST_HEAD
3. register_netdevice succeeds but list remains uninitialized
4. unregister_netdevice_many_notify walks notifier chain calling cfg802154_netdev_notifier_call
5. list operations on uninitialized head cause null pointer dereference and kernel panic

How to detect it

Search kernel logs for BUG: kernel NULL pointer dereference referencing cfg802154_netdev_notifier_call or list.h during netdevice unregister; correlate with ieee802154_if_add and mcr20a_probe call traces.

• BUG: kernel NULL pointer dereference, address: 0000000000000008
• RIP: cfg802154_netdev_notifier_call
• ieee802154_if_add+0x6ed
• mcr20a_probe

What your security team should do

• Prioritize kernel update containing the listed commit for any systems exposing IEEE 802.15.4 interfaces
• Monitor EPSS trend and re-evaluate if new exploit code appears given stable low score
• Restrict local access and hardware probe paths on systems using mcr20a or similar drivers until patched