From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dvalin.narfation.org (dvalin.narfation.org [213.160.73.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 900B41F130B for ; Sun, 28 Jun 2026 04:48:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.160.73.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782622106; cv=none; b=Y8uMPvU7BXR+hIc1RSEVCE9nXJZZrGKWPDrOwY6vmLnNRivj8QSU082hu+Rqk6J746/t2FrTEk36pTmZgvr311kNB/Z6xXhZ30qmhMuTqowFvuxga2BUPTzWBMLYewARZ6n1xIqmw5uTnwVwIskp3lbRUwKR+gPv9gxIvAwP5JI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782622106; c=relaxed/simple; bh=tHjdRTECDRv+r8uUeCkKKTNay+DUwQuCON3jaaPDuyU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=FllViOPrYfr0ki89HDIij61yi3De3YA1Hq9elkaBrx+oq8YjIhxGZV5EPVHbglymxWsk+wewY5rK+6TgiE9tFm8YPCWP+kEJKIgj73xKKniDcQYndyHVT2C6TU3Cmryn49QYI5KnvtSqBFvwANVfHIVVhS3HI/f8Kks2+k3N7tg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org; spf=pass smtp.mailfrom=narfation.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b=lN+ua4ju; arc=none smtp.client-ip=213.160.73.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=narfation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=narfation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=narfation.org header.i=@narfation.org header.b="lN+ua4ju" Received: by dvalin.narfation.org (Postfix) id 64CC91FF41; Sun, 28 Jun 2026 04:48:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narfation.org; s=20121; t=1782622101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=gp1aunLY4MC/a0Zn+kTuixZYk458uLrU1eNpIe9Y3sI=; b=lN+ua4juX/eUX1jd6omrB9Iqa3eZZIrWj9ACE8mLT8VPW+QWrP3FSJhenPFK0J0HFg4EaE tGT2+L7ibY6YmX2XJ2OkRxEExAufszjdIew8BabaWhHOBWOBT+QkdMYoFPmfNx3HZbCuXN SFbL2AOZ/C2lrB16J2wm8IK6zidR4yw= From: Sven Eckelmann To: WenTao Liang , linux-kernel@vger.kernel.org, b.a.t.m.a.n@lists.open-mesh.org Subject: Fwd: Re: [PATCH] fix: net/batman-adv: batadv_interface_kill_vid: extra batadv_meshif_vlan_put after destroy Date: Sun, 28 Jun 2026 06:48:16 +0200 Message-ID: <2572903.ElGaqSPkdT@sven-desktop> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5239390.GXAFRqVoOG"; micalg="pgp-sha512"; protocol="application/pgp-signature" --nextPart5239390.GXAFRqVoOG Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Sven Eckelmann Date: Sun, 28 Jun 2026 06:48:16 +0200 Message-ID: <2572903.ElGaqSPkdT@sven-desktop> MIME-Version: 1.0 ---------- Forwarded Message ---------- [...] New issues: - [High] Removing the final `batadv_meshif_vlan_put()` call in `batadv_interface_kill_vid()` introduces a permanent reference count leak, preventing the VLAN object from ever being freed or unlinked from `meshif_vlan_list`. [...] -- commit 0818db7c27664fbdfdce2f408c5630f66e16ed4d Author: WenTao Liang fix: net/batman-adv: batadv_interface_kill_vid: extra batadv_meshif_vlan_put after destroy This commit removes a batadv_meshif_vlan_put() call in batadv_interface_kill_vid() to address a suspected refcount underflow and potential use-after-free. > diff --git a/net/batman-adv/mesh-interface.c b/net/batman-adv/mesh-interface.c > index 44026810b99ce..e39c9c0ffe46e 100644 > --- a/net/batman-adv/mesh-interface.c > +++ b/net/batman-adv/mesh-interface.c > @@ -693,9 +693,6 @@ static int batadv_interface_kill_vid(struct net_device *dev, __be16 proto, > > batadv_meshif_destroy_vlan(bat_priv, vlan); > > - /* finally free the vlan object */ > - batadv_meshif_vlan_put(vlan); > - [Severity: High] Does removing this batadv_meshif_vlan_put() call introduce a permanent reference count leak? batadv_meshif_create_vlan() assigns a base refcount of 1 representing the list's ownership. In batadv_interface_kill_vid(), batadv_meshif_vlan_get() acquires a temporary reference, incrementing the count. batadv_meshif_destroy_vlan() then drops the list's base reference. Doesn't the caller still need to drop its temporary reference with this second put() to reach a refcount of 0 and trigger batadv_meshif_vlan_release()? > return 0; > } [...] --nextPart5239390.GXAFRqVoOG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQS81G/PswftH/OW8cVND3cr0xT1ywUCakCnkAAKCRBND3cr0xT1 y/pxAPwKLuASbUUctnhbNEKgDJQBAsRZ5D+qL9b3ry21tDzDAQEAhXHuPdkO1DMp 0BVy2i/S2qE1sDmx0cHLra0c9c8HhAQ= =wiGu -----END PGP SIGNATURE----- --nextPart5239390.GXAFRqVoOG--