From: "Pali Rohár" <pali@kernel.org>
To: Mahmoud Adam <mngyadam@amazon.com>
Cc: gregkh@linuxfoundation.org, stfrench@microsoft.com,
stable@vger.kernel.org, linux-cifs@vger.kernel.org
Subject: Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points
Date: Sun, 1 Dec 2024 13:37:35 +0100 [thread overview]
Message-ID: <20241201123735.ssqp4v6q57ygmxt5@pali> (raw)
In-Reply-To: <lrkyqmshny9qt.fsf@dev-dsk-mngyadam-1c-a2602c62.eu-west-1.amazon.com>
On Monday 25 November 2024 09:54:02 Mahmoud Adam wrote:
> Pali Rohár <pali@kernel.org> writes:
>
> > On Friday 22 November 2024 14:44:10 Mahmoud Adam wrote:
> >> From: Pali Rohár <pali@kernel.org>
> >>
> >> upstream e2a8910af01653c1c268984855629d71fb81f404 commit.
> >>
> >> ReparseDataLength is sum of the InodeType size and DataBuffer size.
> >> So to get DataBuffer size it is needed to subtract InodeType's size from
> >> ReparseDataLength.
> >>
> >> Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer
> >> at position after the end of the buffer because it does not subtract
> >> InodeType size from the length. Fix this problem and correctly subtract
> >> variable len.
> >>
> >> Member InodeType is present only when reparse buffer is large enough. Check
> >> for ReparseDataLength before accessing InodeType to prevent another invalid
> >> memory access.
> >>
> >> Major and minor rdev values are present also only when reparse buffer is
> >> large enough. Check for reparse buffer size before calling reparse_mkdev().
> >>
> >> Fixes: d5ecebc4900d ("smb3: Allow query of symlinks stored as reparse points")
> >> Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
> >> Signed-off-by: Pali Rohár <pali@kernel.org>
> >> Signed-off-by: Steve French <stfrench@microsoft.com>
> >> [use variable name symlink_buf, the other buf->InodeType accesses are
> >> not used in current version so skip]
> >> Signed-off-by: Mahmoud Adam <mngyadam@amazon.com>
> >> ---
> >> This fixes CVE-2024-49996, and applies cleanly on 5.4->6.1, 6.6 and
> >> later already has the fix.
> >
> > Interesting... I have not know that there is CVE number for this issue.
> > Have you asked for assigning CVE number? Or was it there before?
> >
> Nope, It was assigned a CVE here:
> https://lore.kernel.org/all/2024102138-CVE-2024-49996-0d29@gregkh/
>
> -MNAdam
I did not know that somebody already assigned it there.
It would be nice in future to inform people involved in the change about
assigning CVE number for the change.
next prev parent reply other threads:[~2024-12-01 12:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 13:44 [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points Mahmoud Adam
2024-11-22 14:56 ` Sasha Levin
2024-11-22 15:20 ` Mahmoud Adam
2024-11-23 12:20 ` Pali Rohár
2024-11-25 8:54 ` Mahmoud Adam
2024-12-01 12:37 ` Pali Rohár [this message]
2024-12-01 12:44 ` Greg KH
2024-12-01 12:47 ` Pali Rohár
2024-11-25 2:16 ` kernel test robot
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=20241201123735.ssqp4v6q57ygmxt5@pali \
--to=pali@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-cifs@vger.kernel.org \
--cc=mngyadam@amazon.com \
--cc=stable@vger.kernel.org \
--cc=stfrench@microsoft.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox