From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (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 62D4F38E126 for ; Tue, 6 Oct 2026 12:29:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791289764; cv=none; b=H8hRh9J4eTPLxCteefuKamFL5GE90Oy3fandePAYT4S8XdU2XteColydl5A28oU3wsK7QlQsZnvU90DWhuXCgpyVHuGYgCrlnakmMDS1AbhBcFltUY103KS9f2OTNo/URwfk3a7KbJFqurKVuMrODuFf0u/dtY/WNFxPPVR++6g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791289764; c=relaxed/simple; bh=lthPC1Aid3RzMwkXHABVJupMtn6Oz9nfXWocpfXLG6E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MPE14NmqfQlEvjgqTfzLZ72Yzoc0ijPrdQ0OEzw4HX5ZzQYSXyvHO71xeozNno+zSr7/VH8ZNHAMHTgCSodd58HAeAu86youSbtynImayo3QLlRZAEa6xv/Csg6jD9RkFKCBNr/F3+Zg+W2b+EjKdRlGgs8qqsTlIZDdpIcR33k= 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=dLmfm469; arc=none smtp.client-ip=209.85.210.176 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="dLmfm469" Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-85377c8bc96so365758b3a.3 for ; Tue, 06 Oct 2026 05:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791289763; x=1791894563; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=UBXDjxHdeZnn0EE9oAZG0kH7xmYbT9bOqu8043JSOZo=; b=dLmfm469wfkY2FSQWsUOZQhiEeKazJlefm23rKBSNdpucKHj+mL8yieV/v1s8tbFOX O0baBUY1QjIEi9LhWYZY7YWjty4rBjuxL+buE30zmdcUf8R9hB1QH4lTWkQeomnRPmMD Vjz6Ax0Nd8j7OE7Z4l60nYKXC1sxG5crZ8pyuQsgtV8XlBgFMnGlC+5nMORgfkXzbo7h vNEHw3sizjmxQ2BWc09viMSKxVRfLEUNpH7e0Hqky5BVn90E9K0UV9EbppgPyffDfmpT vLfFS4gQA7ZuDW1fXkjr/zGLzfbSHk454IljA2lUcwHaSDjFJJcBDwwzgVx9sEI1uRJb mJew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791289763; x=1791894563; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=UBXDjxHdeZnn0EE9oAZG0kH7xmYbT9bOqu8043JSOZo=; b=rdrRokR6RzkigU2oq6u84gcSJgyF2hHiEttjgYMFV+YH3ZL9/4tqarZ1klfn1jWrNy VubN1IRcdp7J2n7a6xWVgyB0sD9qP+S0XySQ1KLnMTga0IyjinAweSArd6rJQoDwEZcl MzzWQODxrI8lctr6wWia9mFgbxqdimI1PQkxqJN7ICmooAD70YXEfHREVCRXTkfHl1XJ 5bAxhpNeAsWEjqy6iWVgRPfYBsQjR5dpnLcDObL8RM2PHWpIoxK6e3hld/IgFAB1e8Ut SCHJ9WtAPgpsNjXAtGIupBFL+zHoVQ641/wThCVzc8elNiEOhkS4sQpAHz6d1ZL+ES55 PRmQ== X-Forwarded-Encrypted: i=1; AKwUvBzyY4v/XPqnwHu2gzESXCX6Mw/repURBkSEzynij+cpmlcTAB39RHBqrrsEN+KR/kiekE4akts0jAHgwJ0=@vger.kernel.org X-Gm-Message-State: AFuF++nNCIg9hmHv7jTuO8y2643P2BSS6UAuI6La0jB6yGWRgtj15iwg 5gp+k+uWBD968vclpLDXnOs/XxlB2ZWlAMUXfVrtX3R7XGSTjIt0dyea X-Gm-Gg: AYBFou1mMhNwJjqvBMcG2B9hiSH0/vgwb9rcDKJzN3aAQDTb624Tg9uDjO3ZicqUGM+ MuDM953pi0wc6pQKw335/4cT2N/8b3z3dSvCXzi3HJgilfLLSxTe+ckUYjPcb8t9ox8nVyfexhS e0E+rWq3SP4GAFVwDDckD5dZ1M45E3RlGqmpMPaqDEnKnGpW8SPb875TJFewVBMf8KAHZAN5C8X 2eY8N7kARo08ly6+YR15gi/pUF2fAGfcBecCRXugO8Di517y8Llf66UXd9m3G/hqUCHfp4hqngK P58ap3osG4Z3ZQrherVA/wUnwPfdT1yRYxvIGb5IM9zS4C63dCDhKzjYkGFbNjvEsaG6QMIBbN+ RxpzjLHUNQ8cfxxqCGpMKB+n8DZgR8sljbIpA1hUkQCGED2vgQn9y6iJGpRVSYYfJaNYnmkCLl9 //dDzm5G10sPugVPiZCZaJknutdZDjWai2UhvWtYFOb0yCnJarC60vRZ7kOZKCNnalVzs+ye5rT OggfYv/hdz2tJ+J X-Received: by 2002:a05:6a00:1792:b0:869:9298:ba59 with SMTP id d2e1a72fcca58-890d8a4ec77mr1125260b3a.0.1791289762603; Tue, 06 Oct 2026 05:29:22 -0700 (PDT) Received: from LAPTOP-450UDG4J ([2401:4900:6310:b8da:d139:f8fd:7043:7eb2]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-88b0c88a815sm4679332b3a.42.2026.10.06.05.29.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 05:29:21 -0700 (PDT) From: Yogesh Gaur To: Song Liu , Yu Kuai Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, Li Nan , Xiao Ni , Christoph Hellwig , Hannes Reinecke , Logan Gunthorpe , Yogesh Gaur , syzbot+95eeb4ada2349a2170ea@syzkaller.appspotmail.com, stable@vger.kernel.org Subject: [PATCH v2] md: don't hand out the array before md_alloc() has added mddev->kobj Date: Tue, 6 Oct 2026 17:59:04 +0530 Message-ID: <20261006122904.1538-1-yogeshgaur.83@gmail.com> X-Mailer: git-send-email 2.55.0.windows.5 In-Reply-To: <20261004055712.1293-1-yogeshgaur.83@gmail.com/> References: <20261004055712.1293-1-yogeshgaur.83@gmail.com/> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit md_alloc() publishes the gendisk before it is done setting the mddev up: disk->private_data = mddev; ... error = add_disk(disk); if (error) goto out_put_disk; kobject_init(&mddev->kobj, &md_ktype); error = kobject_add(&mddev->kobj, &disk_to_dev(disk)->kobj, "%s", "md"); add_disk() makes /dev/mdN openable. mddev comes from mddev_alloc() and is zeroed, so anything that gets in between add_disk() and kobject_add() sees an mddev->kobj that has never been through kobject_init() - no ktype, no kref, state_initialized clear. syzbot opens the array in that window and issues ADD_NEW_DISK: kobject: '(null)' (ffff8880120640f0): is not initialized, yet kobject_get() is being called. WARNING: lib/kobject.c:642 at kobject_add_internal+0xea/0xcd0 lib/kobject.c:225 kobject_add_varg lib/kobject.c:374 [inline] kobject_add+0x163/0x240 lib/kobject.c:426 bind_rdev_to_array+0x80c/0xdd0 drivers/md/md.c:2621 md_add_new_disk+0xe3b/0x1850 drivers/md/md.c:7684 md_ioctl+0x200a/0x2610 drivers/md/md.c:8499 bind_rdev_to_array() is not the only way in. md_run() calls sysfs_create_group(&mddev->kobj, &md_redundancy_group), and internal_create_group() has its own WARN_ON(!kobj->sd), so RUN_ARRAY in the same window warns too. Every ioctl that can reach mddev->kobj runs under reconfig_mutex, so hold it across add_disk() and kobject_add(). An ioctl issued in the window now waits for md_alloc() to finish instead of seeing a half-built mddev, and opening the array still succeeds. The ioctls md_ioctl() serves without the mutex only read array state and return -ENODEV on an array with no disks. Hoisting kobject_init() above add_disk() is not an option: commit ca39f7502425 ("md: fix mddev->kobj lifetime") moved it below add_disk() so that md_alloc()'s error paths, which free the mddev directly, never see an initialised kobject. Fixes: ca39f7502425 ("md: fix mddev->kobj lifetime") Reported-by: syzbot+95eeb4ada2349a2170ea@syzkaller.appspotmail.com Suggested-by: Yu Kuai Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Yogesh Gaur --- v2: Hold reconfig_mutex across add_disk() and kobject_add() instead of refusing the open in md_open(), per Yu Kuai's review: v1 made an open that raced with md_alloc() fail. v1: https://lore.kernel.org/all/20261004055712.1293-1-yogeshgaur.83@gmail.com/ Built with W=1 only, fix has not been runtime-tested. drivers/md/md.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 67108c397c5a..85439f27d943 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -5906,12 +5906,22 @@ struct mddev *md_alloc(dev_t dev, char *name) disk->events |= DISK_EVENT_MEDIA_CHANGE; mddev->gendisk = disk; + + /* + * add_disk() makes the array openable before mddev->kobj exists. + * Hold reconfig_mutex until kobject_add() is done so that ioctls + * issued in between wait instead of using an uninitialised kobj. + */ + mddev_lock_nointr(mddev); error = add_disk(disk); - if (error) + if (error) { + mddev_unlock(mddev); goto out_put_disk; + } kobject_init(&mddev->kobj, &md_ktype); error = kobject_add(&mddev->kobj, &disk_to_dev(disk)->kobj, "%s", "md"); + mddev_unlock(mddev); if (error) { /* * The disk is already live at this point. Clear the hold flag -- 2.55.0.windows.5