From nobody Mon Dec 1 22:35:43 2025 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 70678239E6C for ; Thu, 27 Nov 2025 16:54:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764262451; cv=none; b=cGx4TX3ftuuACNddUH7Y8NbG7RP33FwEX6EXHJpukfv+eOGpkSQStYFY/U5mIYqSLXTNazZQ4SFfbc8EsrVSogw6tKxh38+n3O97hDAUtSwngDSTyAaKyKRX8CjQDjrJthA/FqHV/kxYE1eRaCQ0OtdkGiUwbzc0M65aRo7+eV8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764262451; c=relaxed/simple; bh=pW4aGxkyJzlDY8mzHVYKMSn48+6DhevnhNrwrfll3fE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VzcKedhyC/6kDPnUYGXJ6mNW012IPtP2ViAN+pc8260iN4VEbNu/4Bre/0pFK/9CLalgmt8jV6422bvRtoZvg96H5psQ3480E8kP0d7D5khMwssrdnLyVj1+wXtFs/jXZ5nifsinFZN8scmq4kLtSgNOD/x5E/Sml1qyLkuixdM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SFS0ufNX; arc=none smtp.client-ip=209.85.210.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SFS0ufNX" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-7acd9a03ba9so1173656b3a.1 for ; Thu, 27 Nov 2025 08:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764262450; x=1764867250; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ExKtXnnneeww6lun1Yn14XCHi1VlQQEOBvjuqcrngAo=; b=SFS0ufNXn/GQTqxA7Opof11B6xIwBbCaEHHQ80cHkcYNnBFbeF6GLgrq+DR62anpt9 7daaAQBbPwhasT1i8qNZmZN3mUKLm9m09l429CxMnmV4vw8tGbvaoB9ykP3tPgZQ/+bu cWpmKQj/MU3/s8+ZMHS6Mah2+4Nnr8EB1yaVStfHKbu+LP3RQVT1bsA5lm0gc8IIn4va hrnHAo8dhOZGgzfnTYPFFu1XvGM4PMYQdYLKqe27p+AvHNyUZ8dv5P20dlwfUYG1UdNf ASoXvun0p/TGMG4/XbM2eSYy6vTI6m7k3VRwS1TRUC1LNpfXmzytgf/wNlxeEHhIik15 NGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764262450; x=1764867250; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ExKtXnnneeww6lun1Yn14XCHi1VlQQEOBvjuqcrngAo=; b=peYAIRy4oPp+YOPnYD+57GgHqifWOlPKUxKTB4AHGg14msgNLLJDBurfnQi2LwSLUi aHSBxkj4OyO0aJF5A7pCGGKQ+42O/P1+LCyHWG6zrw7cHGdGoaryJV6EztXNg7kD+Gj7 wt3h9GZbTYj9ohkOZGJOuaDA7cn1BixI7WWUqlqQrhofM0t2TFnibUaBDHfjOMWbcAjK VXyefsRxbuwiYsu3W1Lr8mqUNntgUFZicG5JnkgY2WpOoEhvVeFXdneB+VZljt+J+aJl Xlq2wBaEWEUvietvT2v1dd1C+9ThrVhDNVSbzIpPMAfgfVR/nyESCRfBHo9eaXVzzsJz OkJA== X-Forwarded-Encrypted: i=1; AJvYcCWPrmkSHz54sWus20lUXGKONJpvlOMeDkzJiXfnCb3FeBL1hYfLxeiEJDpsSXUHWlHYzm3F0fSMfN/d4Fc=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+wKKQ3M8ZcAwWMzwilIyRAHTqLP4oUUnQC4x6cUEEuOW7JMPX 9f1TctExXoU9lxJ8WLGnOc8p3MjUxi1c148E9s1KChwuI1DCi5fNICRe X-Gm-Gg: ASbGnctZWSjXYoPX8vc0s/zWFlE27GvywPBUI3wgbKk6WGZ8MRphZEBgkhFhHaRnqs6 nMzd1QLfTcoSTTWAkU9bHLW7qoQTML/9whaphk5w7nbS8U2LEcL2K1IXB+dn5vTQCBhLJgJFKKR cTqrVEyNzCY7wl4B/MJx+usNEyYsgefg7iof417P8i3Qcc0IA3WsWo1a6l8ZkKEqI8R+Ry8goAX G3EMjRl/28t36jY/0gBs8nhS2WzpA6voS/CJojRFY17kgX5Gg7kAYBacb/CyNddJLpHSFyNuPeJ QWl//H0rYXSYW43HyGceFENgTI7UO3CyRe/b9GrX1/SzN3hAN9v/334DnPgWeWc9CLerMoWEK4i BCTt/q8wevOeVLcFUt4d+L8HTBGE2hvy/4Xnxv5RAAL9OqKWXmHEqwUFDmB5KbRpvHb8KoQ9303 ecFpPUD7sa1FH7Ys/CqIdQ4msGcd2lOWFHHGXzySJxmqnDZX0JNuiOpUulhx2B6FSIe3/MPWNER bgBt2D8ZATEeNW9R5MmePJx6YKQ6GOkh6VtnFkshIseHAeJXH/RiLyfyg8k6vO7HhQkShj6hSHT kr3GX5XhbugEDRNXwFJVcYilxQn3utjR2A== X-Google-Smtp-Source: AGHT+IFJ1v7QO6JslFxK1flOhHU+oJ1gZXfCghqcfNz5B9Ti0HUk4aTCJymj0eR745ra+Bs5ORAWdg== X-Received: by 2002:a05:6a00:1803:b0:7b6:dd81:db74 with SMTP id d2e1a72fcca58-7c58c999e9emr26931048b3a.12.1764262449642; Thu, 27 Nov 2025 08:54:09 -0800 (PST) Received: from cyberkunju.asia-south1-c.c.gen-lang-client-0196962068.internal (125.31.93.34.bc.googleusercontent.com. [34.93.31.125]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7d15f175d95sm2404197b3a.45.2025.11.27.08.54.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Nov 2025 08:54:09 -0800 (PST) From: Navaneeth K To: parthiban.veerasooran@microchip.com, christian.gromm@microchip.com, gregkh@linuxfoundation.org Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, abdun.nihaal@gmail.com, dan.carpenter@linaro.org, Navaneeth K Subject: [PATCH v4] most: core: fix resource leak in most_register_interface error paths Date: Thu, 27 Nov 2025 16:53:37 +0000 Message-ID: <20251127165337.19172-1-knavaneeth786@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface. Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths. The most_register_interface() is expected to call put_device() on error which frees the resources allocated in the caller. The put_device() either calls release_mdev() or dim2_release(), depending on the caller. Switch to using device_add() instead of device_register() to handle the split initialization. Acked-by: Abdun Nihaal Signed-off-by: Navaneeth K Reviewed-by: Dan Carpenter --- Changes in v4: - Removed the '!iface->dev' NULL check as suggested by Dan Carpenter. - Updated commit message to explicitly explain how put_device() triggers the caller's release function (suggested by Dan Carpenter). Changes in v3: - Dropped USB cleanup patch (already applied upstream). - Added Acked-by. drivers/most/core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/most/core.c b/drivers/most/core.c index da319d108ea1d..6277e6702ca8c 100644 --- a/drivers/most/core.c +++ b/drivers/most/core.c @@ -1286,15 +1286,19 @@ int most_register_interface(struct most_interface *= iface) !iface->poison_channel || (iface->num_channels > MAX_CHANNELS)) return -EINVAL; =20 + device_initialize(iface->dev); + id =3D ida_alloc(&mdev_id, GFP_KERNEL); if (id < 0) { dev_err(iface->dev, "Failed to allocate device ID\n"); + put_device(iface->dev); return id; } =20 iface->p =3D kzalloc(sizeof(*iface->p), GFP_KERNEL); if (!iface->p) { ida_free(&mdev_id, id); + put_device(iface->dev); return -ENOMEM; } =20 @@ -1304,7 +1308,7 @@ int most_register_interface(struct most_interface *if= ace) iface->dev->bus =3D &mostbus; iface->dev->groups =3D interface_attr_groups; dev_set_drvdata(iface->dev, iface); - if (device_register(iface->dev)) { + if (device_add(iface->dev)) { dev_err(iface->dev, "Failed to register interface device\n"); kfree(iface->p); put_device(iface->dev); --=20 2.43.0