From nobody Mon May 25 03:33:12 2026 Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) (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 B9F0D3EDABB for ; Tue, 19 May 2026 09:52:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779184337; cv=none; b=nB8z+NrLhiW/UmBZmkxNjaT7ypzp70nFQ8FlTBenBR813Bm+Cqb63sBf+xBD8rje91a5Xx4V+E+YSVZcZSjK1HvqM+lDs2WpWW4PwP7EzjuKu1NzVACSZZxbzFeITv7rk8pmEc6K/SCHhPE2l9zeP7lQeNl/sAY8UxS/JU2WLO8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779184337; c=relaxed/simple; bh=oj+KFARW3atpzddg8zMv78o7rWNm5zu9UJAVmegL0XA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aCiNjc8T3MGVCgWkfRCmEqD2nXjNPnV4rDXvji9cEm2+1okqiMepxTOVvPPbYk92z2uoeqXBnK6wVOx8mDcmYwLX0qrVmuYl+anMLzdolfKhdL2/udCcL/peiRg47aHOGGbQFXOpxhlRPLLq2tIFYYAbNba9Gqj1C2UoEVOvGes= 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=CHZleOm/; arc=none smtp.client-ip=209.85.219.50 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="CHZleOm/" Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-8acb3daf2aaso62166496d6.0 for ; Tue, 19 May 2026 02:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779184335; x=1779789135; 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; bh=cRCR11qUHaj3Qg7MbFr/xCdePGzcx00slw0JQNYdwuQ=; b=CHZleOm/JM2oZlAx/Yz1dXBxriKZ7D+ctjN5+ZKaYuOP2oUDIEMcTHDoSCWNBZ8sT4 aa73cDa/zOdoqDwUsBedfimfcjIL9Dwn3psFXZ9gdGmo2cHPYAvtUyAeAlf5oKjaAa+B kK9YcZ1LGGu8A6udFnFSzQCFzR9fycH54bv66r1z2VOto28z/sTyq61aspZQ4iDr9F7B 8xfCjaENdgQbpTLK29gRcH6uV+6D6LrGbt7deQJK/LI1Jj+3aKXauUxwQrjdF2jI1O/J 5fP16bxkvGGl12+JfY0FT18Jmib9Yv9Fn58bUih16YIOxGQB0Qu0iEgS0jpuHq/TNCAo 998Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779184335; x=1779789135; 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; bh=cRCR11qUHaj3Qg7MbFr/xCdePGzcx00slw0JQNYdwuQ=; b=CFeutsmec0ACxSUGP5ZDN+6YKt5vqf891ZEgPZKEqClY7+iV+VWA1aKHW8Rt8wXvOe us/IAMJ/dO528QJQYL/6oDs3P83PO+muOdDO5Bu0h9ZWLYbH1Cg8P1JTBgIs1UfWR6Ax mlpwyypO6JYjIrjH+JJeEq0Lra5AD4j7Kpv1t5F6tC+g0agcYDGxvUgVYhciNhkQ5NDo yUNTzSxDcp6uA8FzrRzPgwmK2E9Go2YGqpcpM7y2lzXJYObnrhbAp8Xqq/4u02GgXj/J QxsMD0h7ifyYoGdteB1iMpNqaOnsABPHaBGf7VwoU+xgvwD0s+7PpFmJLinmLS9Q3rWB yIPg== X-Forwarded-Encrypted: i=1; AFNElJ9fhI6k0YSCMsHGNBkZQFqyiulkNNNdYSjyXNxs5hO8RfZZ+y7wYO8CBK9CZSEBWl8salL6L85Jm6sBT2k=@vger.kernel.org X-Gm-Message-State: AOJu0YxshzUG7xdqk72bCTAe0v8AS6M7gG61tauOjau5Xk8m8etg9xO6 tk8rrqqt8w+n9xeKzEBNhyE4D2H0rP+s+zNb6oXpqfXdiW+N93CgbO3Mgl/PF4bC X-Gm-Gg: Acq92OFpao1Vcvlhu9Hg4j8PMCooP9rtLNOKtjD8AzbY6BqWgRnuUdsIWBRJZXZZw3m CpRt90UUB0Ia6WzOECZTx/8gIBCZHOJ679+CiBnZGqvAKP0qRw8nxetbI2EY9ujJkTwZ8xWI6Y5 3TxVoX0GIgl6RGEYCEIbY9IE4mWSuvpREIXKAU07x7Oo3HMt0tIFIbPx62H2otoaK/5AcLo2Li8 KaPOD356Qo8ndd8V74xr239SOTOpaN8H+5ZxpjGpMPyPYaRu1F8J0SDLczgbeG1nmwMYbMFiXTQ lscpKeIJQxDORvaEXH43rfYfNSzsRvUWUWfT6KhPUnIAPDCQo/JPqIOE5uWvfoLhtC4srAXHIR6 7pPaqCXl6bbd/6tklGOxzKvu2Q6qv+yg4e9uy+sKmvITtrc7/dB1QWBgwAQl57MbPKtRVnvX1eo hph4xP+NKz1gbxtYr5zhcWSS2UUrKhIv1FmzqjgCjPbR7aEbYe/TpwaxQVPSjSJaEYY87tc7mJu U3RRbsgVrzkCy7LZnCU X-Received: by 2002:a05:6214:4e06:b0:8ca:1dd8:10c with SMTP id 6a1803df08f44-8ca1dd803bemr234592946d6.30.1779184334701; Tue, 19 May 2026 02:52:14 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ca3619c7d9sm84697036d6.36.2026.05.19.02.52.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 02:52:14 -0700 (PDT) From: Michael Bommarito To: Konstantin Komarov Cc: ntfs3@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Pavitra Jha Subject: [PATCH v2] fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} Date: Tue, 19 May 2026 05:51:35 -0400 Message-ID: <20260519095135.1609973-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260515163424.1575298-1-michael.bommarito@gmail.com> References: <20260515163424.1575298-1-michael.bommarito@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: quoted-printable Content-Type: text/plain; charset="utf-8" In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <=3D e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch "fs/ntfs3: prevent oob in case UpdateRecordDataRoot" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Reported-by: Pavitra Jha Closes: https://lore.kernel.org/ntfs3/20260502105008.21827-1-jhapavitra98@g= mail.com/ Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito --- v2: - Add Pavitra Jha's Reported-by trailer and a Closes tag for the original public report, as requested in review. fs/ntfs3/fslog.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c index acfa18b84401e..127860fd2ab50 100644 --- a/fs/ntfs3/fslog.c +++ b/fs/ntfs3/fslog.c @@ -3497,6 +3497,18 @@ static int do_action(struct ntfs_log *log, struct OP= EN_ATTR_ENRTY *oe, =20 e =3D Add2Ptr(attr, le16_to_cpu(lrh->attr_off)); =20 + /* + * e->view.data_off and dlen come from the on-disk + * INDEX_ROOT entry / LRH. The neighbouring read sites + * (e.g. fs/ntfs3/index.c) check that + * view.data_off + view.data_size <=3D e->size; mirror that + * bound here so the memmove cannot reach past the entry. + */ + if (le16_to_cpu(e->view.data_off) > le16_to_cpu(e->size) || + le16_to_cpu(e->view.data_off) + dlen > + le16_to_cpu(e->size)) + goto dirty_vol; + memmove(Add2Ptr(e, le16_to_cpu(e->view.data_off)), data, dlen); =20 mi->dirty =3D true; @@ -3689,6 +3701,12 @@ static int do_action(struct ntfs_log *log, struct OP= EN_ATTR_ENRTY *oe, goto dirty_vol; } =20 + /* See UpdateRecordDataRoot for the rationale. */ + if (le16_to_cpu(e->view.data_off) > le16_to_cpu(e->size) || + le16_to_cpu(e->view.data_off) + dlen > + le16_to_cpu(e->size)) + goto dirty_vol; + memmove(Add2Ptr(e, le16_to_cpu(e->view.data_off)), data, dlen); =20 a_dirty =3D true; --=20 2.53.0