CVE-2024-46673

What it actually does

Double-free in aacraid driver when aac_init_adapter fails after allocating aac_dev::queues without clearing the pointer, allowing aac_probe_one error path to free the same memory again and cause memory corruption.

Why it matters to the business

Linux systems using aacraid hardware face risk of kernel crashes or local privilege escalation during device probing; patch promptly despite low observed exploitation to avoid downtime on servers and workstations with these controllers.

How an attack unfolds

A local attacker triggers hardware-specific init failure after queue allocation inside aac_init_adapter, causing the subsequent error path in aac_probe_one to perform the second free and corrupt kernel memory structures for potential code execution.

How to fix it

Update to Linux kernel containing commit d237c7d06ffddcdb5d36948c527dc01284388218 or equivalent stable releases that clear the queues pointer on aac_init_adapter failure.

How to confirm the fix worked

Confirm presence of the pointer-clearing change in aac_init_adapter, rebuild and boot test kernel on aacraid hardware while simulating init failure, and verify no double-free warnings appear in dmesg.

Typical attack path

1. Obtain local user access on target Linux system
2. Arrange conditions that cause aac_init_adapter to fail after queues allocation
3. Trigger aac_probe_one error path to execute double-free
4. Leverage resulting memory corruption for privilege escalation or denial of service

How to detect it

Inspect kernel logs for aacraid init failures followed by memory corruption or slab double-free messages; correlate with unexpected panics during device enumeration on systems with Adaptec RAID controllers.

What your security team should do

• Apply the referenced kernel commit or newer stable branch on all systems exposing aacraid devices
• Limit local unprivileged access on servers using this hardware until patched
• Review kernel logs for aacraid probe errors as an indicator of exposure