CVE-2022-48783

What it actually does

Use-after-free in gswip_remove() where of_node_put on the slave MII bus device node occurs after mdiobus_free, allowing access to already-freed memory in the Linux kernel DSA driver.

Why it matters to the business

Kernel crashes, potential memory corruption, or remote code execution on affected network hardware can cause service outages and require urgent patching across device fleets.

How an attack unfolds

An attacker with local access or the ability to trigger device removal/unbind invokes gswip_remove, causing the driver to free the MII bus before releasing the associated device node reference, enabling subsequent use of dangling pointers for corruption or code execution; threat actor mentions of Android kernel RCE indicate possible similar patterns in embedded kernels.

How to fix it

Upgrade the Linux kernel to a version containing commit 15af22fc22bc6030fcead322c106f07640336115 (or equivalent backport) that reorders of_node_put before mdiobus_free; apply vendor-specific DSA driver patches for embedded devices.

How to confirm the fix worked

Confirm the reordering of of_node_put before mdiobus_free appears in the gswip_remove function in the running kernel source or via binary diff of the driver module; test device removal paths do not trigger use-after-free warnings in KASAN-enabled builds.

Typical attack path

1. Obtain ability to load/unload the lantiq_gswip module or trigger device removal
2. Trigger gswip_remove execution path
3. Exploit the window where the of_node has been freed after mdiobus_free
4. Perform memory manipulation or ROP to achieve privilege escalation or denial of service

How to detect it

Search kernel logs for use-after-free warnings or slab corruption reports referencing gswip or lantiq_gswip during module unload or device removal; inspect crash dumps for references to mdiobus_free followed by of_node operations.

What your security team should do

• Prioritize kernel updates on all systems using lantiq_gswip DSA hardware within the next 30 days given the published date and lack of KEV listing
• Audit embedded device firmware images for the vulnerable gswip driver
• Enable KASAN or similar memory safety tooling in test environments to validate the fix
• Monitor for any downstream dependents affected by this networking driver change