From nobody Mon Jun 15 20:34:37 2026 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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 0BDAD3CCFAC for ; Mon, 13 Apr 2026 13:56:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776088604; cv=none; b=tO7IVwcaz6aXpLmhfeoIH4Ko91m0w6ZCIDDHzSoXnFQnUzXeTJdoJX7HAEPPQBXUUvcH2Nuf25qng5TPLhRu4DDKPge1rehJIK6QJbTji2LmM858T3pRGssrx3DurugDg/mQt2tkr47WvHHZcT1Gvv6FB1pPQhORcOWAMG0Uz8Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776088604; c=relaxed/simple; bh=Hpvv+IN2EELEEcnD5YwW84ys/b/L7dP7YW1BRzo/t8U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=F9QDNXgFpgIFOCcTfizu14un2fFMENFLrmHvGmR/Okr38C1Yj+Yj6+2SS5MTyZqv2ubewwFSSsp/8slR2eGQILT6gaAIS7POOcaYQglJB4gVOo23SpaBuM2uNH89Q/8ratGiFgjWAvmBmRMGFTB8JObxI+PZFmxbAtl0PVnH1jc= 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=kVhPRJuD; arc=none smtp.client-ip=209.85.214.174 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="kVhPRJuD" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2aae146b604so32002705ad.3 for ; Mon, 13 Apr 2026 06:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776088602; x=1776693402; 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=IwI7fhoIYuDnAceYOXsnx6dLQgMpnwbjObgo8mwaSj4=; b=kVhPRJuDq7yFzsHSk2U9Vb5efnwz6LzIgQSv9kE4LTe1GsvjMdpKz89Hg2pDWkHXdA sTTYSQBzdsv8N8HXDedTb7q159RjfBKKZ+cI/rKMSZFhIUpEnPYkL9G8CU4arhq7KEg+ dZc7njBroO+FiLHvMYTi8tldCTI8JZ1aShsHXodD52bzww56ToamtqpCbd9dG1AXTa9m dDhTwzF6veIMjzpK6rhqDnIRMglcz7bLvOYijIXdZSVFcpOhk539mR4qS5BzQ/tqrWoS g5Pwi8W85anYs6EdOymUqRBLNFH443TSmQ+xkDrBSM+CBlcA9x86Osg0OVa88qZ7EdHR 28JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776088602; x=1776693402; 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=IwI7fhoIYuDnAceYOXsnx6dLQgMpnwbjObgo8mwaSj4=; b=g3+/SyEs3yog6hrdv4sAFLkIBZHJX8APc+RCr4kVRgdtBpsa+nketrjh8xh0eygZEp E2qJGJuUSAc4BRbCYmJfL77hzIoRnh0V8TvrilhHHQs1qCqRs9nu5PBPKJGvAisS9jhA AvIIrSzEBujkQeU/P2PUf2zMWvoXjiY+u/NOQm80ZNazuNerBBL77p0PZ2u/51y9r9ZA 6nsNv5Kvrc3o9ppy4iGR0T1TIQjg0s1l/LHkih7qBi0JsBweeerooaRKDWrEAsToz6yp pXhis2tMT53YOqMd2Irly8M1kEOYJV2BVyquqKB1ph5l4URKqt0yDqemgvPLT/dzHIZU hdWg== X-Forwarded-Encrypted: i=1; AFNElJ+6STN+cdGQL/BJXBgtnJ9BrUafwbZDNNF32TCqQWROaprqusWdoAwwYjTW7Irka0dcQrV+CO7E9qI4tHs=@vger.kernel.org X-Gm-Message-State: AOJu0YyJPtWuL0A0x6RAOIpCUNRosdDnw+i4UAViR7raJKAlleaRMyaZ yCZKmI0tH+ZVFl57LjtQxu/5dcrefTiGMg8N5GxrJvElpd3PHIEFX6so X-Gm-Gg: AeBDietV9UMiS33nn816Q0IigmK2yYrZfwDzBwqLtatgN3uAlv9ua5anEQbs0U1ITJf 27OgQmuQ4P4S+TwMDXpR+Zcr/9u+xp/z0X4L2tSVsv0U/jYf6/KngaufNRGTTVgy4sLEjDZyI2x vKTakG2HO3QM7PU1lLRXAn/u5/7u7VZbsorAOwPuRy6MwrMuXb4lge8iaJk6TMAWF8R665Fvi2d vBB/gcUUgJHIUjyv89Nv2Gocngy6R60+gYERfMz+e+mHTsovafz+n/hoGDRrLu56kEGJiPkLiz4 6F9VOYHNbcnOkxBcudc9pxk7n+Xp0pmLC3EwyElEikrCzQW56+KMY9wJxTQhNn37iCh1j+pxdjj 8Gjn+N7wy49ChHAljjnYEi2JpuocrVIFpGJwl6Bhzlz0pOc4XCjZL02V+M+ojkh2ZevCel4N3RQ OaFnCxWFo7sEMFgNEKJHt4qsLEZ3YNh4U= X-Received: by 2002:a17:902:b698:b0:2b2:aa93:cc5f with SMTP id d9443c01a7336-2b2d597609dmr100423715ad.10.1776088602230; Mon, 13 Apr 2026 06:56:42 -0700 (PDT) Received: from lgs.. ([2409:893d:1188:142d:6c67:74e8:5200:1f39]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b468273ccfsm12585665ad.43.2026.04.13.06.56.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2026 06:56:41 -0700 (PDT) From: Guangshuo Li To: Dan Williams , Vishal Verma , Dave Jiang , Andrew Morton , nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Guangshuo Li , stable@vger.kernel.org Subject: [PATCH v3] device-dax: Fix refcount leak in __devm_create_dev_dax() error path Date: Mon, 13 Apr 2026 21:56:25 +0800 Message-ID: <20260413135625.2890908-1-lgs201920130244@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" After device_initialize(), the embedded struct device in dev_dax is expected to be released through the device core with put_device(). In __devm_create_dev_dax(), several failure paths after device_initialize() free dev_dax directly instead of dropping the device reference, which bypasses the normal device core lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by assigning dev->type before device_initialize(), so the release callback is available, use put_device() in the post-initialization error paths, and keep dev_dax range cleanup explicit since it is not handled by dev_dax_release(). Fixes: c2f3011ee697f ("device-dax: add an allocation interface for device-d= ax instances") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li --- v3: - note that the issue was identified by my static analysis tool - and confirmed by manual review v2: - clarify the commit message around the device reference leak - drop the unsupported use-after-free claim - set dev->type before device_initialize() so put_device() can use the release callback on post-init failures - simplify the post-initialization error paths to use explicit range cleanup plus put_device() drivers/dax/bus.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c index fde29e0ad68b..2d92674d0d6e 100644 --- a/drivers/dax/bus.c +++ b/drivers/dax/bus.c @@ -1453,6 +1453,7 @@ static struct dev_dax *__devm_create_dev_dax(struct d= ev_dax_data *data) } =20 dev =3D &dev_dax->dev; + dev->type =3D &dev_dax_type; device_initialize(dev); dev_set_name(dev, "dax%d.%d", dax_region->id, dev_dax->id); =20 @@ -1499,7 +1500,6 @@ static struct dev_dax *__devm_create_dev_dax(struct d= ev_dax_data *data) dev->devt =3D inode->i_rdev; dev->bus =3D &dax_bus_type; dev->parent =3D parent; - dev->type =3D &dev_dax_type; =20 rc =3D device_add(dev); if (rc) { @@ -1522,14 +1522,13 @@ static struct dev_dax *__devm_create_dev_dax(struct= dev_dax_data *data) return dev_dax; =20 err_alloc_dax: - kfree(dev_dax->pgmap); err_pgmap: free_dev_dax_ranges(dev_dax); err_range: - free_dev_dax_id(dev_dax); + put_device(dev); + return ERR_PTR(rc); err_id: kfree(dev_dax); - return ERR_PTR(rc); } =20 --=20 2.43.0