CVE-2023-52629

What it actually does

Use-after-free in the push-switch driver caused by flush_work() executing before timer_shutdown_sync() in switch_drv_remove(), allowing a timer callback to reschedule work that accesses freed memory.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel memory corruption leading to crashes, privilege escalation, or denial of service; the issue affects many embedded and server distributions but has low observed exploitation risk.

How an attack unfolds

An attacker with local access loads or triggers the push-switch driver, times removal of the module while a timer fires on another CPU to reschedule work, then accesses the freed psw structure inside the work handler to corrupt kernel memory.

How to fix it

Update the Linux kernel to a version containing commit 610dbd8ac271aa36080aac50b928d700ee3fe4de or later; rebuild and reboot all affected systems; verify the driver is not in use during removal if custom modules are present.

How to confirm the fix worked

Confirm the presence of commit 610dbd8ac271aa36080aac50b928d700ee3fe4de in the running kernel source or package; attempt module removal under load while monitoring for use-after-free reports in dmesg; re-test timer and work ordering in the push-switch code path.

Typical attack path

1. Obtain local code execution on a vulnerable Linux kernel
2. Trigger switch_drv_remove while switch_timer is active on another CPU
3. Allow schedule_work to queue after flush_work but before kfree
4. Execute use of the freed psw object inside switch_work_handler
5. Leverage resulting memory corruption for privilege escalation or DoS

How to detect it

Search kernel logs for use-after-free reports referencing switch_work_handler or psw state access after module removal; review audit logs for unusual module unload sequences on systems exposing the push-switch device.

What your security team should do

• Prioritize kernel upgrades on all systems using the push-switch driver within the next maintenance window
• Monitor EPSS and threat intelligence for any increase in exploitation activity
• Harden local access controls and reduce unnecessary module loading to limit attack surface
• Include the fixed commit hash in SBOM and vulnerability scanning policies