case study

[bniladridas]

----------------------------------------------------------------------------------------------------------------------------------

Kernel race condition case study: Appletalk AARP UAF

In the Linux kernel, a use-after-free vulnerability was recently resolved in the Appletalk AARP proxy probe path.

The issue stems from a classic race condition in aarp_proxy_probe_network(): the routine sends a probe, drops aarp_lock, sleeps, and then re-acquires the lock. During this window, an independent expire timer (__aarp_expire_timer) can reclaim and kfree() the same aarp_entry, resulting in a use-after-free when execution resumes.

The race manifests across CPUs as follows:

cpu 0                                | cpu 1
------------------------------------ | ---------------------------------
atalk_sendmsg()                      | atif_proxy_probe_device()
aarp_send_ddp()                      | aarp_proxy_probe_network()
mod_timer()                          | lock(aarp_lock)
timeout (~200ms)                     | alloc(aarp_entry)
aarp_expire_timeout()                | proxies[hash] = aarp_entry
lock(aarp_lock)                      | aarp_send_probe()
__aarp_expire_timer()                | unlock(aarp_lock)
free(aarp_entry)                     | msleep(100)
unlock(aarp_lock)                    | lock(aarp_lock)
                                     | use-after-free

KASAN reliably detects the fault, flagging a slab use-after-free in aarp_proxy_probe_network() with the freed object reclaimed by the expire timer path. The crash trace highlights how subtle lock-release + sleep patterns can invalidate object lifetime assumptions even in relatively mature subsystems.

This serves as a concrete example of why temporal safety, lifetime ownership, and concurrency discipline remain critical in low-level systems code ==> especially when timers, work queues, and sleepable paths intersect.

---

Why this matters now

As we’ve moved from M1 to M4 systems over the course of this year, our compute stack increasingly blends high-performance local execution with heterogeneous and remote accelerators. These transitions amplify the importance of:

• Deterministic concurrency behavior
• Strong invariants around object lifetimes
• Tooling such as KASAN to surface otherwise silent failures

The same principles apply whether you’re debugging kernel networking code or designing hybrid CPU/GPU execution paths.

---

🔗 About: https://bniladridas.github.io/hybrid-compute/