From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 619863EDAA0 for ; Thu, 7 May 2026 15:48:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778168939; cv=none; b=O2dzIRResxbcgAHDf6EODlNpDVZOLL2nryKhNoxsk+dGf/XjYFtXdnjRH3roCjJqbVronNl+1EQVJq7CUjPvyH6ppW200jSPhjJ2N+Zf/TJ0MrypY9asWBPJ6bZE5kf5BsqIXhpXK0t1vSH2hTxzXwHSCeQ1HGwiRzwcCkR5otk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778168939; c=relaxed/simple; bh=qkNoeGkk1EDvbqr2YYvb3ZfhLuvKkUA3Dp1BcLHOb58=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=WBqRtOyYL8uoFmw1ryQj63xGFR2LYFYJxqdB4n6Y8CrTGSHXmsF71oKJ+AnKR1FGydPfPYQ90QC1w9D9vdxjTc9huR5qeHh3YCq8frdDpjENXwEI0ddTpwxLJQiFFsNL13ff02z6AUKnbGplioYZ1BHsBO+Mysl2EVl2v6jamDM= 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=qhGJkbhg; arc=none smtp.client-ip=209.85.214.169 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="qhGJkbhg" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2ad2b375e58so460725ad.3 for ; Thu, 07 May 2026 08:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778168938; x=1778773738; 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=eKm6d3Tcv+zN5MgNnW1QNHFyC06/mNbb0XfWewjzA7k=; b=qhGJkbhg+NPu4JCwV8ENh5FWLh3qTGrdbnjpoDhIRxxcip1qqT2SNnJJvUrqwBFGEI XQEWeKsfk/0hEhj0+HkGLZRzqr1VzhTBy3GcYVm4ku1xSndtrkxHkYGXIxY4Af9wdffc RsZF88qFeia+D78rxJiyt2CnTNg9bjGqw9d/pwiAvks6Z33iIqFsH4E+Rfx3kg31IIv3 nIPOWUsD97JXpoywo+A+1JXHEN0Ll/fKMdl4J8ct9PEbSg2NOKTsB49WH/lfg+WLzOvr RzvxZp1Qq6t1kzwK2ILCKagJhjJfZlx7XNz37Uqb4OiKjcZeci3ZD4WAElkB25wjo4XM ewzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778168938; x=1778773738; 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=eKm6d3Tcv+zN5MgNnW1QNHFyC06/mNbb0XfWewjzA7k=; b=NcWiuj3wHQWxQm0kOqMH47apoaG3Sm89pLHK2OV4WUGxcIM6aQvrDVTPyn8eKcOS0L onB998JOP1DHEb50/d8/wJn7Kh4merfW5Ppcp8mddu3pRsSfYoG6yPfh4FfkU4nqT3Ae wLE6WcvxQgRqtFytDsqi9QNDPa8IfOvQfRTEQAB5WLaeGoj4VcYXZi0uE6/pBAV5bGXS oV44Wl5HvE8eu8lN02HusgeVE6v/WZScgOSdApGtOZiVNheERHPIhjC6j7Hzy05ENzHQ GBmEKvdb41nsvng9juGc64mTSAtS+1g5/dGRhoKnNUuNlINn0uPuXH3qa/c1QWLuzivP O1jA== X-Forwarded-Encrypted: i=1; AFNElJ/a7qUovg4MCMyGnrL6dgTspPQSCSnPFxwo0Sq9ixfvV3nB1G8XnYZk2CLUC2zZlJM2odTbdDFjzC0ScW8=@vger.kernel.org X-Gm-Message-State: AOJu0YxFGI14JMhDUncmrgSC3u5yys1lcVYY3DZ7do6JuuZbzlup/uWP OlwLxLEv4sTNLDI94q6cVZLz4JrbteTkO85G1a9Uu2RdsgT7lmQ2U67hiQdaKAkA X-Gm-Gg: AeBDievI2KiGXmlaH/E+Aw1v2EUYq0kWzFwXPpVptfw6Z6UZsodiQkgy6L2HNHgAMkc aaOOJb9MnRU1QLHyrAMuDLomgvHL1Zng1w7DHstPZD06hmdvSiYZLYSvJTTRjJpcMHjY7w1tGWI yVaDQtkA+vlXuQjMcdo4qog2snLQETBCGpYvcQ9zpgUEKeQY3U4RT+HQNfMQ8o74Lhiucw7Zg7S I+rk9uPlmUlP+Cf2NGyjVbjdJvlLlzvZOnZoeZp0osmu5Ce2HWvOROsyydWtcmDlR8ITMvHKrG0 7MArMoVYNBYCJji48UafVTSRO3mxccN9rDIfPbYS2BcNH5oUxUQsJedAycsq8dnUB3KVMyS8Mmz ecWkHGaW4wn534v9hZlVxX9Ya7cN6cFnkgtKH7HPeNnBJeezia+/1yVFHyViv1ewsBpGJNtTZyl 5IhiFvLSapd6f9tidF0ZBZc11aSfo= X-Received: by 2002:a17:902:d2c1:b0:2ba:7662:804f with SMTP id d9443c01a7336-2ba7afccbccmr43919385ad.2.1778168937668; Thu, 07 May 2026 08:48:57 -0700 (PDT) Received: from ser8.. ([221.156.231.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bae7857d8esm934685ad.55.2026.05.07.08.48.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2026 08:48:57 -0700 (PDT) From: DaeMyung Kang To: Namjae Jeon , Hyunchul Lee Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, DaeMyung Kang Subject: [PATCH] ntfs: avoid leaking uninitialised bytes in new security descriptors Date: Fri, 8 May 2026 00:48:52 +0900 Message-ID: <20260507154852.1721710-1-charsyam@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: 8bit ntfs_sd_add_everyone() builds the on-disk security descriptor for a newly created file by kmalloc()'ing a buffer and then partially filling it in: sd = kmalloc(sd_len, GFP_NOFS); ... sd->revision = 1; sd->control = SE_DACL_PRESENT | SE_SELF_RELATIVE; ... The buffer is then handed to ntfs_attr_add() and persisted as the SECURITY_DESCRIPTOR attribute of the new MFT record. The descriptor covers a relative security descriptor header, two SIDs (owner and group), an ACL header, and a single ACE, but several fields inside those structures are never written before the buffer is committed to disk: - struct security_descriptor_relative @alignment (1 byte) @sacl (4 bytes; SE_SACL_PRESENT is not set but the offset still reaches disk) - struct ntfs_sid (3 instances: owner, group, ACE.sid) identifier_authority.value[0..4] (5 bytes per SID, 15 total - only value[5] is set) - struct ntfs_acl @alignment1 (1 byte) @alignment2 (2 bytes) That is 23 bytes of uninitialised slab memory persisted to disk for every new file or directory the legacy ntfs driver creates. The "+ 4" trailing accounting in sd_len holds ace->sid.sub_authority[0], which the existing code does explicitly write to zero, so it is not part of the leak. Anything later able to read the SECURITY_DESCRIPTOR attribute - the same NTFS volume mounted on Windows or by another NTFS reader, an offline forensics tool, an unprivileged user that ends up with read access to the volume - can recover those bytes. The leak persists for the lifetime of the file on disk, not just the lifetime of the kernel that wrote it. Switch the allocation to kzalloc() so every byte the on-disk descriptor covers is zero before the explicit initialisations run. While there, replace the bare "return -1" allocation-failure path with a proper -ENOMEM so the error reaches userspace as a meaningful errno instead of an unrelated -EPERM. Found by inspection while auditing fs/ntfs new-inode paths. Fixes: af0db57d4293 ("ntfs: update inode operations") Signed-off-by: DaeMyung Kang --- fs/ntfs/namei.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ntfs/namei.c b/fs/ntfs/namei.c index dc786270afe5..aad928ebb7bd 100644 --- a/fs/ntfs/namei.c +++ b/fs/ntfs/namei.c @@ -355,9 +355,9 @@ static int ntfs_sd_add_everyone(struct ntfs_inode *ni) sd_len = sizeof(struct security_descriptor_relative) + 2 * (sizeof(struct ntfs_sid) + 8) + sizeof(struct ntfs_acl) + sizeof(struct ntfs_ace) + 4; - sd = kmalloc(sd_len, GFP_NOFS); + sd = kzalloc(sd_len, GFP_NOFS); if (!sd) - return -1; + return -ENOMEM; sd->revision = 1; sd->control = SE_DACL_PRESENT | SE_SELF_RELATIVE; -- 2.43.0