From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 AD886416840 for ; Tue, 18 Aug 2026 07:56:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787039793; cv=none; b=EEZ7YuQPibyRoPVyXhLKpS+2UidmxGWyMnS7P80baVqowo7/z6SStLzB+VD1PQZCprS92sOu60gk4vLlpkWKMTEemMF6MFDwSgnA4EehjPO55YfGSdMKO0aC9qAD+/NVQ1l8J7rznnjU2MBD+sA2kQ5SPrLE7PtTx0zm9qh2nDc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787039793; c=relaxed/simple; bh=wN1G3VLAri2idzxrKhjPTyRvxBaBzkUIdTu06K5bXIs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=r6se6c2iWazAQm3aTMP95jzYnKoVQLTHAk/QNyGozbE6rKkkYclxSl0vi7UGizD8tT8akWOUyN036ROfEyaEcOUKztZROQqFLwQAOKe23sxpFptwxSlVsG6yKKvybhSNjbvNBVKzlzmpj06/pCibe9GaZWcbV8i8/N/BazcOEjM= 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=V98QB6RY; arc=none smtp.client-ip=209.85.210.179 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="V98QB6RY" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-848c995c29dso240812b3a.3 for ; Tue, 18 Aug 2026 00:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787039792; x=1787644592; 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:content-type; bh=PRpAJ7pRHD4AGRp+qfyl7gvWtz4VOamDAw6BNIILlQ8=; b=V98QB6RYJTPR475ODOLxgpv8riY1r2ehiJ/5Ef6l8tNcAxq1FRMCKAzZmGenQCkN/2 mMTZda4KoYdHxwo8cfw9D/7/Hyc2sb4BWEdKtYeRnOR17IRddYFcx15ZaRb6S0w2ZYMk jBwqm9G4yXpD0hn5HfopRwOaaeMKZ3mYa0p9csHyB67l1fVG3ahx8CuSjS5lVOXXIv4q hJ0aKI67ShPkSPdPJcZansqt4a2x254VF70b2EXpE5H7jqNoBGYPStdL/hLx57aJFTh0 HWUQ6EzHmElZnDz8sYl53iKnQTYCxy0KMAocNuCC+HDhqYNUDfrqAYZgiIKIeqqHygcS 17dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787039792; x=1787644592; 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:content-type; bh=PRpAJ7pRHD4AGRp+qfyl7gvWtz4VOamDAw6BNIILlQ8=; b=kehriyIcQbcZ7MGcuW2N2KwhGsGNDyT/2uWT7YK/IvCSVJATld/aWNE5V9FmsRI0Vx GL369bhKdwRkFdkLl/vW9gD9i3iVI5qzlAdKTWyNbLFefY0hHm4MEIZQbgWfNL8yv0lD iJ7he//iMYeOnayT1aHfZBS+2o+aQ57SuYJLKt+N4Nxg1ydh4V3HA+aD+J7WusyFq0JL +x1tiPUenLiBYfNPnQVBlNR90TzXQWSyMfAqQIlWij+uEtA6yT0G/kUqAWCedm1C6b3n +ooIIgfwCmEKnQYEIjUbMPn3fs9bLX01NAQCW8DcoWeSyvmgU/vowNovZWHXt8sYgJAw wpOw== X-Forwarded-Encrypted: i=1; AHgh+RoWa+ygslH3Fd6tPTTXyWL48eI0n1PGBT9Z5PaxR0btNNwqcD8e2/Qy8aNgTfm4/BxRDDv2uTNbx21nwJw=@vger.kernel.org X-Gm-Message-State: AOJu0YwiPiOki0fOMQBP8Ly7w6diN80zF9ftvw2PeP+v2/GeNcP69y9r td2/QiEMdQTCbTs1dnz07uDcqo1UpIqM73qQeY218kBNybEgVCHuEs5UZnPqVHjzvBgxmw== X-Gm-Gg: AR+sD13NVkIdRLrmHuHO6/63mJqvWPFCHUwu18OQb/rhUvif+WM7waXshLy2XzEZx91 t24v6kFwq81jchMXMu5gCHAl2UAVEf6pGH32cVDEHn7D5pfSdi0vvEJIU7xuKcEBdhw7AhUzcoX mEObRmkVTXRm36R8NXY5ZwI+IlgQ5WonRO0HP6FbK0aV5eVRkm0QVpdNBHuEdbwimbAS6brz9Ue 5DnEqxLhbMNdAsrOKXz9/UxYuyif0xeTaO1saTCxOkHpQvQH7QgzjK+2MO6CP9GW0Xrdenj+ZtU BddBdGy5HoAXu0sP1xsidAs7ih+Jba2Vbszhvp+aw+9K1NuRYY8YD0wa+nFMrgF4LuMTVex15bX p18O1aVWyuJCAAvnxpnsrXMUmMKRiebYKRJUVuWirRSMe08hAJgwzXa0iYmRb8ThVgW+uUOHUg0 +UHCD3I3OqGzUQDI7gn5MkL25ph/WPCld5i+viHidyP3mSsUAF5okgD/d681xjflkVQ8HxTYoyk vATUVADIz1f X-Received: by 2002:a05:6a00:4a08:b0:848:5451:cfa8 with SMTP id d2e1a72fcca58-84fdde1e2a1mr16658748b3a.0.1787039791703; Tue, 18 Aug 2026 00:56:31 -0700 (PDT) Received: from localhost.localdomain ([175.159.181.20]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-851b6ff0e3csm1213879b3a.60.2026.08.18.00.56.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 00:56:31 -0700 (PDT) From: Yu Junzhe To: Mike Snitzer , Mikulas Patocka , Benjamin Marzinski , Alasdair Kergon Cc: dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [BUG] dm: unbounded recursion in dm_blk_ioctl via cyclic DM stacking Date: Tue, 18 Aug 2026 07:56:27 +0000 Message-ID: <20260818075627.322-1-junzheyu1@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: 7bit Hello, I am reporting unbounded recursion in dm_blk_ioctl(): it forwards a block ioctl to the underlying device with no depth or cycle guard. A two-device DM-on-DM cycle then re-enters dm_blk_ioctl until the kernel stack is exhausted. Summary ======= dm_prepare_ioctl() lets the single target substitute bdev via prepare_ioctl. dm_blk_ioctl() then calls that disk's fops->ioctl with the original cmd/arg: r = dm_prepare_ioctl(md, &srcu_idx, &bdev); ... r = bdev->bd_disk->fops->ioctl(bdev, mode, cmd, arg); linear_prepare_ioctl / flakey_prepare_ioctl just set *bdev to the underlying device when sizes match. When that device is another DM disk, fops->ioctl is dm_blk_ioctl again. Table load rejects only a device mapped onto itself (dm_get_device: dev == disk_devt(t->md->disk)). A->B->A is accepted. bd_link_disk_holder rejects only a disk holding itself. Ordinary BLKGETSIZE* ioctls on the same cycle return cleanly (handled in the block layer). A DM-style ioctl (DM_VERSION) on the mapped block fd is not handled there and is forwarded unbounded. The shipped PoC uses linear + flakey. linear<->linear is expected to recurse the same way via linear_prepare_ioctl. Affected ======== - Confirmed on Linux 6.6.144 (da47cbc254661aa66d61ef061485a7080305c4be), stack-protector guest - Still present on torvalds/linux master as of 2026-08-18: dm_blk_ioctl still forwards with no depth/cycle check; dm_get_device still only rejects self-map. The later prepare_ioctl forward flag is for target-local handling, not cycle detection (linear still always forwards) - Files: drivers/md/dm.c, drivers/md/dm-linear.c, drivers/md/dm-table.c - Config: CONFIG_DM=y (CONFIG_DM_FLAKEY=y for the shipped PoC topology) Crash excerpt (from minimized PoC) ================================== BUG: TASK stack guard page was hit at ... CPU: 0 PID: 219 Comm: repro Not tainted 6.6.144 #1 RIP: 0010:dm_prepare_ioctl+0x10/0x100 Call Trace: dm_blk_ioctl+0x4d/0xe0 dm_blk_ioctl+0x78/0xe0 dm_blk_ioctl+0x78/0xe0 ... (dozens more recursive dm_blk_ioctl frames) Kernel panic - not syncing: Fatal exception Full oops and a self-contained Docker/QEMU reproducer (poc.c) are available on request. I am happy to test patches or send the reproducer package. Thanks, Yu Junzhe FuzzAnything