[BUG] devlink: region trigger leaks a permanent snapshot id slot on every successful auto-id capture

[BUG] devlink: region trigger leaks a permanent snapshot id slot on every successful auto-id capture

[Guikun Yang]

Hi Jiri, Jacob,

devlink_nl_cmd_region_trigger() (net/devlink/region.c) allocates a
snapshot id via __devlink_region_snapshot_id_get() when the request
does not carry DEVLINK_ATTR_REGION_SNAPSHOT_ID, then creates the
snapshot.  On the success path it returns without ever releasing the
caller's reference, so the id's refcount stays at 2 instead of dropping
to the snapshot-only 1.

__devlink_region_snapshot_id_get() is documented as:

 *	Note that the caller of this function counts as a 'user', in order to
 *	avoid race conditions.  The caller must release its hold on the
 *	snapshot by using devlink_region_snapshot_id_put.

The netlink trigger is its own caller, and nothing in the kernel holds
the id after the command returns, so the hold is never released.

Consequences, per successful auto-id trigger:

  xa_alloc(&devlink->snapshot_ids, id, xa_mk_value(1))   /* count = 1 */
  __devlink_region_snapshot_create()                     /* count = 2 */
  ... success, no put ...

Later, when the snapshot is deleted, devlink_region_snapshot_del()
calls __devlink_snapshot_id_decrement(), bringing the count to 1.
Since it is not zero, the id is NOT erased from the xarray:

 *	If the count reaches zero, erase this id from the xarray, freeing it
 *	up for future re-use by devlink_region_snapshot_id_get().

The slot stays occupied forever.  Every subsequent attempt to use that
particular id fails:

  - __devlink_snapshot_id_insert() rejects it with -EEXIST (xa_load()
    finds the stale entry), so a user can never explicitly re-create a
    snapshot with that id;
  - reading or deleting "the snapshot with that id" returns -ENOENT,
    so there is also no way to clean the stale entry up.

Repeating the trigger leaks one xarray slot each time.  The slots are
small, but the ids are allocated with xa_limit_32b and never reused, so
the snapshot_ids xarray grows monotonically for the lifetime of the
devlink instance, and every id ever handed out by an auto-id trigger
becomes permanently unusable.

For comparison, the failure path is correct:

err_snapshot_capture:
	__devlink_snapshot_id_decrement(devlink, snapshot_id);

which drops the caller's reference (1 -> 0) and erases the slot.  The
explicit-API users (e.g. devlink health reporters) also pair
devlink_region_snapshot_id_get() with devlink_region_snapshot_id_put()
and are fine.  Only the auto-id success path in the netlink trigger
misses the release.

Fix is one line: on the success path of an auto-id capture, release the
caller's reference after the snapshot has been created, e.g. right
before the final unlock:

	if (!snapshot_id_attr)
		__devlink_snapshot_id_decrement(devlink, snapshot_id);

(the snapshot itself holds the remaining reference; when the snapshot
is deleted the count reaches zero and the id is erased and becomes
reusable).

Checked against 7.3.0-rc7 and linux-next (2026-10-24): both carry the
leak.  syzbot has no devlink-region reports, and I found no prior
report on lore/marc.

Reproduced on 7.3.0-rc7 with netdevsim (built-in devlink region
"dummy") using an unmodified upstream config:

  trigger (auto id)            -> snapshot id 2 created
  delete snapshot 2            -> ok (slot refcount 2 -> 1)
  trigger with explicit id 2   -> -EEXIST

Repeating the pair three times allocated ids 2, 3, 4 sequentially and
left every one of them permanently unusable.  PoC is a plain netlink
sequence (DEVLINK_CMD_REGION_NEW without and with
DEVLINK_ATTR_REGION_SNAPSHOT_ID, then DEVLINK_CMD_REGION_DEL), no
special privileges beyond CAP_NET_ADMIN.

Best,
Guikun Yang