CVE-2026-43232 in Linux
Zusammenfassung
von VulDB • 10.05.2026
Implied Question: Based on the provided KASAN (Kernel Address Sanitizer) crash log, what is the root cause of the use-after-free bug, and how can it be fixed?
---
### Analysis of the KASAN Log
#### 1. **Type of Bug** This is a **Use-After-Free (UAF)** bug. - **KASAN detected a bad access** to a memory address that had already been freed. - The buggy address is located **28 bytes inside** a freed 1024-byte region (`kmalloc-1k`).
#### 2. **Timeline of Events** - **Allocation**: The memory was allocated via `kmalloc-1k` (size 1024 bytes). - **Freeing**: The memory was freed by task 41 on CPU 1 at timestamp `75.138639s`. - Call chain for free: ``` kfree() → fst_remove_one() → pci_device_remove() → device_release_driver_internal() → pci_stop_bus_device() → pci_stop_and_remove_bus_device() → disable_slot() → acpiphp_disable_and_eject_slot() → acpiphp_hotplug_notify() ``` - This indicates the memory belongs to a **PCI hotplug-related structure**, likely associated with a function or device being removed during ACPI hotplug events.
- **Use (Bug)**: The memory was accessed **after** it was freed. - Call chain for the buggy access: ``` acpiphp_hotplug_notify() → acpi_device_hotplug() → acpi_hotplug_work_fn() ``` - This suggests that during a subsequent ACPI hotplug notification, the code tried to access a structure that had already been freed by a previous hotplug removal event.
#### 3. **Root Cause** The bug occurs because: - A structure (likely `struct fst` or similar, given `fst_remove_one`) is freed during PCI device removal (`fst_remove_one` → `kfree`). - However, a **pending or delayed ACPI hotplug work item** (`acpi_hotplug_work_fn`) still holds a reference to this structure and attempts to access it after it has been freed. - This is a classic **race condition** or **missing synchronization** between: 1. The PCI device removal path (which frees the structure). 2. The ACPI hotplug workqueue (which may still be processing or has queued work that references the now-freed structure).
#### 4. **Key Observations** - The buggy address is `ffff88800aad1000 + 28`. - The memory was part of a `kmalloc-1k` slab cache. - The free happened in `fst_remove_one`, which is likely part of the **FST (Function Switch Table)** or similar PCI hotplug driver. - The access happened in `acpiphp_hotplug_notify`, which is part of the **ACPI PCI Hotplug** driver.
---
### Solution
To fix this bug, you need to ensure that **no pending work or references** to the structure exist after it is freed. Here are the recommended steps:
#### 1. **Cancel Pending Work** Before freeing the structure in `fst_remove_one`, ensure that any pending ACPI hotplug work related to this device is canceled. - Use `cancel_work_sync()` or `flush_work()` on the workqueue associated with the device. - Example: ```c static void fst_remove_one(struct pci_dev *pdev) {
struct fst *fst = pci_get_drvdata(pdev);
/* Cancel any pending hotplug work */ cancel_work_sync(&fst->hotplug_work);
/* Now safe to free */ kfree(fst); pci_set_drvdata(pdev, NULL); } ```
#### 2. **Add Reference Counting or RCU** If the work item can be queued asynchronously, use **RCU (Read-Copy-Update)** or **reference counting** to ensure the structure is not freed while it is still being accessed. - Example with RCU: ```c static void fst_remove_one(struct pci_dev *pdev) {
struct fst *fst = pci_get_drvdata(pdev);
/* Schedule RCU callback to free after all readers are done */ call_rcu(&fst->rcu, fst_free_rcu); pci_set_drvdata(pdev, NULL); }
static void fst_free_rcu(struct rcu_head *head) {
struct fst *fst = container
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.