Summary

When i915_gem_batch_pool_get() creates new internal GEM object (line 133) and subsequent i915_gem_object_pin_pages() fails (line 138) error path returns ERR_PTR(ret) (line 140) WITHOUT calling i915_gem_object_put(obj). Freshly-created object has refcount=1 (from drm_gem_private_object_init) is not yet linked into any pool list (list_move_tail at 142 not executed) therefore leaked permanently -- neither pool_fini nor any other cleanup path can reach it. Kernel memory leak reachable under memory pressure (pin_pages fails via i915_gem_object_get_pages_internal at i915_gem_internal.c:48-150 returns -ENOMEM from kmalloc/sg_alloc_table/alloc_pages/i915_gem_gtt_prepare_pages). found: label at 137 shared between newly-created (obj NOT in pool list) and recycled (goto found obj already in pool list); on create path pin_pages failure returns ERR_PTR with no cleanup. Contrast recycled path: obj stays in pool correctly reused/freed later by pool_fini. Asymmetry between paths is the bug. Trigger: unprivileged render node user under sustained memory pressure repeatedly submits execbuf ioctls triggering cmd parser path (eb_parse) or GPU-relocation path (i915_gem_execbuffer.c:1153). Impact: kernel memory exhaustion / DoS amplification no UAF no info leak no priv-esc. A:L reflects must first create memory pressure for pin_pages to fail.