CVE-2021-47505

What it actually does

Use-after-free in the kernel's aio poll implementation when a signalfd or binder waitqueue is freed without POLLFREE notification, allowing access to freed memory during non-blocking poll operations.

Why it matters to the business

Local attackers on affected Linux systems may achieve arbitrary code execution or cause kernel crashes, leading to data compromise, service disruption, or full host takeover; the issue affects a wide range of distributions and downstream products though public exploitation remains limited.

How an attack unfolds

An attacker with local access opens a signalfd or binder descriptor, submits an aio poll request against it, then triggers waitqueue release (for example by closing the fd or exiting the task); because aio poll lacks POLLFREE handling the freed waitqueue structure is later dereferenced, resulting in a use-after-free that can be leveraged for memory corruption and privilege escalation.

How to fix it

Upgrade the Linux kernel to a version containing the POLLFREE handling fix for aio poll (backported in stable branches after the referenced patch); rebuild and reboot all affected systems, then verify the running kernel version no longer contains the vulnerable aio poll code path.

How to confirm the fix worked

Confirm the running kernel contains the aio_poll POLLFREE fix by inspecting kernel source or changelog entries referencing the Ramji Jiyani patch; recompile with CONFIG_AIO=y and test that aio poll on signalfd no longer triggers use-after-free under memory-pressure conditions.

Typical attack path

1. Obtain local shell on target Linux host
2. Create signalfd or binder file descriptor
3. Submit aio poll request referencing that descriptor
4. Trigger waitqueue destruction while the aio request is still active
5. Exploit resulting use-after-free for code execution or denial of service

How to detect it

Review kernel logs for aio-related oops or slab-use-after-free warnings involving wait_queue_head or aio_poll; correlate with process activity that opens signalfd or binder descriptors followed by rapid descriptor closure; no widespread in-the-wild indicators have been published.

What your security team should do

• Prioritize kernel upgrades on all internet-facing and multi-tenant Linux hosts within the next patching cycle
• Enable kernel hardening features such as CONFIG_SLAB_FREELIST_RANDOM and page-table isolation where supported
• Monitor vendor advisories for distribution-specific backports and schedule staged rollouts
• Restrict untrusted local accounts from using aio and binder interfaces via seccomp or LSM policies until patches are applied