Summary

ttm_bo_man_get_node captures return value of drm_mm_insert_node_in_range into ret frees node on failure but unconditionally returns 0 instead of ret at ttm_bo_manager.c:88. Every error code (-ENOSPC -ENOMEM) silently discarded caller told allocation succeeded. Confirmed divergence from upstream Linux v5.10 ttm_range_manager.c which returns ret. No memory corruption today: both in-tree callers (ttm_bo.c:908-916 ttm_bo_mem_force_space and ttm_bo.c:1021-1032 ttm_bo_mem_space) check mem->mm_node after call rather than relying solely on return value so callers NULL check catches real outcome (mem->mm_node pre-zeroed). Latent correctness: future caller trusting return code without checking mem->mm_node would treat failure as success deref NULL/stale pointer; error-specific handling lost (-ENOSPC vs -EINVAL both become 0) degrades eviction/fallback logic. Reachable from unprivileged GPU client BO creation ioctl flowing through ttm_bo_mem_space -> man->func->get_node. No security exploit against current callers.