[Bug 295774] ahci(4): ahci_ch_attach() leaks slot DMA maps on attach failure
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 01 Jun 2026 15:01:39 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295774
Bug ID: 295774
Summary: ahci(4): ahci_ch_attach() leaks slot DMA maps on
attach failure
Product: Base System
Version: 14.4-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: bugs@FreeBSD.org
Reporter: lihaoxiang@isrc.iscas.ac.cn
Created attachment 271402
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=271402&action=edit
call ahci_slotsfree() from ahci_ch_attach() error path
An attach failure after ahci_slotsalloc() leaks the per-slot busdma maps
created for that AHCI channel. On the tested QEMU ICH9 AHCI device,
ch->numslots is 32, so each failed channel attach leaked up to 32 DMA maps.
This is a kernel resource leak and may contribute to denial of service under
repeated attach failures or resource pressure.
I reproduced this in QEMU by booting FreeBSD 14.4-RELEASE/amd64 with the root
disk on IDE and a dummy disk on an emulated ICH9 AHCI controller. I built an
instrumented kernel that forces ahci_ch_attach() to fail after
ahci_slotsalloc() has completed, and added probes to ahci_slotsalloc() and
ahci_slotsfree().
No ahci_slotsfree() probe output was observed during or after the failed attach
attempt. Since newbus does not call DEVICE_DETACH() when DEVICE_ATTACH()
returns an error, ahci_ch_detach() is not invoked to call ahci_slotsfree().
Therefore, the slot DMA maps allocated earlier in ahci_ch_attach() are not
released on the attach failure path, nor are they cleaned up later by the
framework.
Thus, Call ahci_slotsfree(dev) on the ahci_ch_attach() error path after
releasing ch->mtx and before destroying it. This matches the detach-time
ordering needed by the per-slot callouts initialized with ch->mtx.
--
You are receiving this mail because:
You are the assignee for the bug.