CVE-2022-48787

What it actually does

Use-after-free in the iwlwifi driver: when no firmware loads, device_release_driver calls remove which invokes iwl_drv_stop to free the drv struct, yet subsequent code still dereferences the freed pointer.

Why it matters to the business

Kernel memory corruption on Linux systems with Intel wireless hardware can cause crashes, denial of service, or local privilege escalation; low EPSS and no KEV listing reduce immediate external risk but patching remains necessary for affected kernels.

How an attack unfolds

An attacker with local access triggers a firmware load failure path in iwlwifi (for example by removing or corrupting firmware files), causing the driver to unbind and free drv, then erroneously access the freed structure; listed threat actor references appear unrelated to this specific Linux kernel path.

How to fix it

Update the Linux kernel to the fixed commit d3b98fe36f8a06ce654049540773256ab59cb53d or later stable releases that contain the change; rebuild and reboot with the corrected driver.

How to confirm the fix worked

Confirm the running kernel contains commit d3b98fe36f8a06ce654049540773256ab59cb53d via git log or kernel version string; attempt firmware-absent boot scenarios in a test environment and verify no use-after-free occurs.

Typical attack path

1. Obtain local access on a Linux system using Intel Wi-Fi hardware
2. Cause firmware loading to fail entirely
3. Trigger device unbind which calls remove and iwl_drv_stop
4. Trigger the erroneous post-free access to the drv structure
5. Leverage resulting memory corruption for crash or code execution

How to detect it

Review kernel logs for iwlwifi unbind and remove sequences coinciding with oops or slab-use-after-free reports; correlate with attempts to load or access firmware files; no widespread exploitation indicators are known.

What your security team should do

• Prioritize patching all affected Linux kernels to the fixed commit within standard change windows
• Inventory systems using iwlwifi hardware and schedule reboots after upgrade
• Monitor upstream stable kernel releases for backports of the fix
• Apply defense-in-depth such as firmware integrity checks where feasible