Export limit exceeded: 10559 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10559 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-90255 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix the SCO setup context lifetime hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 ("Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue. | ||||
| CVE-2026-90151 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection. | ||||
| CVE-2026-90180 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: block: mtip32xx: synchronize ioctls with device removal The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down. | ||||
| CVE-2026-90189 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: null_blk: register configfs subsystem after creating default devices In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] <TASK> [ 2366.547831] ? _raw_spin_lock+0x84/0xe0 [ 2366.548260] add_disk_fwnode+0x114/0x560 [ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk] [ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk] [ 2366.549906] ? mutex_lock+0xde/0x1c0 [ 2366.550361] ? __pfx_mutex_lock+0x10/0x10 [ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk] [ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk] [ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470 [ 2366.552748] ? configfs_write_iter+0x35c/0x4e0 [ 2366.553242] configfs_write_iter+0x286/0x4e0 [ 2366.553787] vfs_write+0x52d/0xd00 [ 2366.554169] ? __pfx_vfs_write+0x10/0x10 [ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10 [ 2366.555196] ? fdget_pos+0x1cf/0x4c0 [ 2366.555649] ksys_write+0xfc/0x1d0 ...... Additionally, the err_dev path destroys all devices on nullb_list while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, null_destroy_dev()->null_free_dev() kfrees the user device's nullb_device but /sys/kernel/config/nullb/<name> is still reachable. Any userspace access to the item will trigger a UAF. For simplicity, move configfs_register_subsystem() to the end to solve the problems above. | ||||
| CVE-2026-90172 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: smbdirect: destroy QP before mem pools on accept failure On the rdma_accept_failed error path of smbdirect_accept_connect_request(), the receive io posted just above is owned by the QP (recv_io is set to NULL after a successful post). The error path fell through to smbdirect_connection_destroy_mem_pools() before smbdirect_connection_destroy_qp(), so the mem pools and the recv_io slab cache were destroyed while that recv_io was still outstanding on the QP. The drain in smbdirect_connection_destroy_qp() (ib_drain_qp()) is what runs the recv completion that returns the recv_io to the free list, so destroying the pools first leaves the object outstanding at kmem_cache_destroy() time ("Slab cache still has objects") and later frees it into an already-destroyed mempool (mempool_free_bulk NULL-pointer dereference). Give rdma_accept_failed its own teardown that drains the QP first, then destroys the mem pools, and returns. The remaining labels (post_recv_io_failed onward) run before the recv_io was ever posted, so they keep the mem-pools-then-qp order. The outstanding recv_io at kmem_cache_destroy() time: [ 3487.344647] ============================================================================= [ 3487.349942] BUG smbdirect_recv_io_cache_ffff88811ba99000 (Not tainted): Objects remaining on __kmem_cache_shutdown() [ 3487.356078] ----------------------------------------------------------------------------- [ 3487.356078] [ 3487.356738] Object 0xffff8881511c3440 @offset=13376 [ 3487.358464] Allocated in mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254 [ 3487.361197] mempool_alloc_noprof+0x18c/0x290 [ 3487.361542] smbdirect_connection_create_mem_pools+0x405/0x780 [ 3487.361972] smbdirect_accept_connect_request+0x5a8/0x1b80 [ 3487.362359] smbdirect_listen_rdma_event_handler+0x1579/0x1b90 [ 3487.362779] cma_cm_event_handler+0x9c/0x230 [ 3487.363096] cma_ib_req_handler+0x2682/0x45d0 [ 3487.363414] cm_process_work+0x56/0x3d0 [ 3487.363676] cm_work_handler+0x8a0e/0xd000 [ 3487.367496] process_scheduled_works+0xa07/0x13a0 [ 3487.367859] worker_thread+0x7c9/0xc80 [ 3487.368148] kthread+0x341/0x430 [ 3487.368407] ret_from_fork+0x3a8/0x7a0 [ 3487.368704] ret_from_fork_asm+0x1a/0x30 [ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2) [ 3487.372840] ------------[ cut here ]------------ [ 3487.373195] WARNING: mm/slub.c:1244 at __slab_err+0x1a/0x30, CPU#6: kworker/6:84/22254 [ 3487.373759] Modules linked in: [ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B 7.1.0-next-20260623+ #88 PREEMPT(lazy) [ 3487.374778] Tainted: [B]=BAD_PAGE [ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3487.378515] Workqueue: ib_cm cm_work_handler [ 3487.378820] RIP: 0010:__slab_err+0x1a/0x30 [ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093 [ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80 [ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080 [ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410 [ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210 [ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300 [ 3487.388932] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000 [ 3487.389529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0 [ 3487.390440] PKRU: 55555554 [ 3487.390641] Call Trace: [ 3487.390826] <TASK> [ 3 ---truncated--- | ||||
| CVE-2026-90387 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: swiotlb: Preserve allocation virtual address for dynamic pools swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator. | ||||
| CVE-2026-93054 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same "device gone" state as normal uio_unregister_device(). | ||||
| CVE-2026-90214 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths. | ||||
| CVE-2026-90392 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF when reading bpf link info In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields. | ||||
| CVE-2026-93137 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm | ||||
| CVE-2026-90270 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: arm_mpam: Disable driver unbind to avoid UAF When a user unbinds an MSC and that MSC is the only MSC left for a component then the corresponding mpam_component will be freed. If the user then goes on to read the schemata file in the resctrl filesystem then the mpam_component will be accessed from resctrl_arch_get_config() leading to a use after free. As the MPAM driver is not a module the unbind sysfs interface is the only way to trigger the remove. Instead of dealing with the complexity of allowing some unused MSC to unbind just remove the unbind sysfs interface. | ||||
| CVE-2026-90292 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint. | ||||
| CVE-2026-90423 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix UAF in ODP init error-handling path rxe_odp_mr_init_user() stores &umem_odp->umem in mr->umem before calling rxe_odp_init_pages(). If rxe_odp_init_pages() fails, rxe_odp_mr_init_user() releases umem_odp and returns an error. rxe_reg_user_mr() then unwinds the error through rxe_cleanup(), rxe_mr_cleanup(), ib_umem_release(mr->umem). There is an IS_ERR_OR_NULL(umem) check at the start of ib_umem_release(). But since mr->umem is NOT reset to NULL in the error handling path of rxe_odp_mr_init_user(), the check passes and it reads already-freed fields like umem->is_dmabuf, causing UAF. Fix the UAF by clearing mr->umem after releasing the failed ODP umem so the MR cleanup path does not release it again. | ||||
| CVE-2026-90429 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init A user VINTF is torn down by tegra241_cmdqv_deinit_vintf(), which runs from the destroy callback and from the init-failure unwind in the alloc handler. It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but nothing serializes that against the error interrupt: tegra241_cmdqv_isr() reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is about to be freed (a use-after-free). deinit_vintf() also returns idx to the IDA before clearing the slot, so a concurrent create that reuses idx can publish its new vintf into the slot, only for this teardown to erase it again with the stale NULL store. On the other end, tegra241_cmdqv_init_vintf() publishes a new vintf with a plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of a published vintf such as vintf->base. A plain store gives no ordering on a weakly-ordered CPU, and a stale VINTF_ERR_MAP bit on a reused idx can make the ISR pick a vintf the moment it is published, before its fields are set or tegra241_vintf_hw_init() runs. The cmdqv->vintfs[0] slot stays NULL until tegra241_cmdqv_init_structures() first creates VINTF0, so the slot 0 read needs the same NULL check. Publish every slot with an smp_store_release(), and read each slot in the ISR with an smp_load_acquire() under a NULL check, so the ISR always sees a fully built vintf or NULL. Also make deinit_vintf() clear the slot, and synchronize_irq() prior to returning idx to the IDA, so no vintf is freed under a running handler and no reused idx is clobbered. | ||||
| CVE-2026-92511 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_cq_user() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. | ||||
| CVE-2026-93039 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.4 High |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message. | ||||
| CVE-2026-93042 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Terminate all descriptors without callbacks The DMA Engine client documentation says in the "Terminate APIs" section of Documentation/driver-api/dmaengine/client.rst: "No callback functions will be called for any incomplete transfers." dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires. | ||||
| CVE-2026-92507 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_dealloc_pd_user() When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. | ||||
| CVE-2026-92508 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. | ||||
| CVE-2026-92510 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_srq_user() When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable. | ||||