From: hewei-gikaku <skyexpoc@gmail.com>
To: Weiming Shi <bestswngs@gmail.com>
Cc: Xiang Mei <xmei5@asu.edu>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
ntfs3@lists.linux.dev, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs/ntfs3: fix out-of-bounds write in ni_create_attr_list()
Date: Fri, 26 Jun 2026 22:11:22 +0900 [thread overview]
Message-ID: <20260626131122.1341-1-skyexpoc@gmail.com> (raw)
In-Reply-To: <20260624053008.4885-2-xmei5@asu.edu>
Hi Weiming, Xiang,
I posted a fix for this exact ni_create_attr_list() out-of-bounds write
two weeks before this patch, to the same list and CC'ing the same
maintainer:
v1 (2026-06-10): https://lore.kernel.org/all/20260610002929.51765-1-skyexpoc@gmail.com/
v2 (2026-06-25): https://lore.kernel.org/all/20260625031932.9412-1-skyexpoc@gmail.com/
Same root cause, same Fixes: tag. The two patches differ in how they fix
it, and the difference matters:
- This patch keeps the fixed al_aligned(record_size) buffer and returns
-EINVAL as soon as an entry would cross the buffer end. Because each
ATTR_LIST_ENTRY (le_size(0) = 0x20) is larger than the minimum resident
attribute it represents (SIZEOF_RESIDENT = 0x18), the list can grow past
a single record_size for a sufficiently full base record, so this can
fail a normal setxattr/file operation with -EINVAL instead of handling
it.
- My v2 computes the exact list size from the attributes first and
allocates accordingly, closing the overflow without introducing that
regression.
Given the earlier posting and that v2 fixes the bug without rejecting
otherwise-valid records, I'd suggest taking v2. I'm happy to rebase it or
adjust to whatever Konstantin prefers.
Thanks,
HE WEI
prev parent reply other threads:[~2026-06-26 13:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 5:30 [PATCH] fs/ntfs3: fix out-of-bounds write in ni_create_attr_list() Xiang Mei
2026-06-26 13:11 ` hewei-gikaku [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260626131122.1341-1-skyexpoc@gmail.com \
--to=skyexpoc@gmail.com \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=bestswngs@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
--cc=xmei5@asu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.