CVE-2022-48742

What it actually does

Use-after-free in __rtnl_newlink() replay logic when master_dev and m_ops are not refreshed inside the loop, allowing stale pointers to freed objects.

Why it matters to the business

Kernel crashes, potential privilege escalation, or denial of service on Linux systems performing network interface configuration, increasing operational risk and downtime for any dependent services.

How an attack unfolds

An attacker sends crafted netlink messages that force replay of __rtnl_newlink(), leaving master_dev/m_ops pointing to freed memory that can then be dereferenced for arbitrary read/write or code execution.

How to fix it

Upgrade the Linux kernel to a version containing commit 2cf180360d66bd657e606c1217e0e668e6faa303 or later; apply distribution-specific security updates that backport the fix.

How to confirm the fix worked

Confirm presence of the fix commit in kernel source; run regression tests exercising rtnetlink newlink replay scenarios; verify no UAF warnings under syzkaller or similar fuzzers.

Typical attack path

1. Obtain privileges to send rtnetlink messages (CAP_NET_ADMIN)
2. Craft netlink requests that trigger replay path in __rtnl_newlink()
3. Trigger memory free of master_dev while stale pointers remain
4. Reuse freed memory to achieve kernel code execution or crash

How to detect it

Search kernel logs for use-after-free or slab-out-of-bounds warnings tied to rtnetlink; inspect audit logs for unusual netlink activity from untrusted processes.

What your security team should do

• Prioritize kernel upgrades on all exposed systems within standard patch windows
• Restrict CAP_NET_ADMIN to trusted processes only
• Enable kernel hardening features such as KASAN and hardened usercopy
• Monitor for kernel oops/panic events involving rtnetlink