From: Greg KH <gregkh@linuxfoundation.org>
To: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Cc: stable@vger.kernel.org, vegard.nossum@oracle.com,
Namjae Jeon <linkinjeon@kernel.org>,
Yuezhang Mo <Yuezhang.Mo@sony.com>,
Maxim Suhanov <dfirblog@gmail.com>,
Sungjong Seo <sj1557.seo@samsung.com>,
Sasha Levin <sashal@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5.15.y] exfat: check if filename entries exceeds max filename length
Date: Mon, 21 Aug 2023 18:43:33 +0200 [thread overview]
Message-ID: <2023082122-remold-emission-a564@gregkh> (raw)
In-Reply-To: <20230819075337.3270182-1-harshit.m.mogalapalli@oracle.com>
On Sat, Aug 19, 2023 at 12:53:37AM -0700, Harshit Mogalapalli wrote:
> From: Namjae Jeon <linkinjeon@kernel.org>
>
> [ Upstream commit d42334578eba1390859012ebb91e1e556d51db49 ]
>
> exfat_extract_uni_name copies characters from a given file name entry into
> the 'uniname' variable. This variable is actually defined on the stack of
> the exfat_readdir() function. According to the definition of
> the 'exfat_uni_name' type, the file name should be limited 255 characters
> (+ null teminator space), but the exfat_get_uniname_from_ext_entry()
> function can write more characters because there is no check if filename
> entries exceeds max filename length. This patch add the check not to copy
> filename characters when exceeding max filename length.
>
> Cc: stable@vger.kernel.org
> Cc: Yuezhang Mo <Yuezhang.Mo@sony.com>
> Reported-by: Maxim Suhanov <dfirblog@gmail.com>
> Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [Harshit: backport to 5.15.y]
> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
> ---
> The conflict resolved patch for 6.1.y applies cleanly to 5.15.y as
> well.
> Note: This fix is already present in 5.10.y but missing in 5.15.y
Thanks for catching this, now queued up.
greg k-h
prev parent reply other threads:[~2023-08-21 16:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-19 7:53 [PATCH 5.15.y] exfat: check if filename entries exceeds max filename length Harshit Mogalapalli
2023-08-21 16:43 ` Greg KH [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=2023082122-remold-emission-a564@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Yuezhang.Mo@sony.com \
--cc=dfirblog@gmail.com \
--cc=harshit.m.mogalapalli@oracle.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=sj1557.seo@samsung.com \
--cc=stable@vger.kernel.org \
--cc=vegard.nossum@oracle.com \
/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.