[PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Mahmoud Adam]

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.
 fs/smb/client/smb2ops.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
index d1e5ff9a3cd39..fcfbc096924a8 100644
--- a/fs/smb/client/smb2ops.c
+++ b/fs/smb/client/smb2ops.c
@@ -2897,6 +2897,12 @@ parse_reparse_posix(struct reparse_posix_data *symlink_buf,
 
 	/* See MS-FSCC 2.1.2.6 for the 'NFS' style reparse tags */
 	len = le16_to_cpu(symlink_buf->ReparseDataLength);
+	if (len < sizeof(symlink_buf->InodeType)) {
+		cifs_dbg(VFS, "srv returned malformed nfs buffer\n");
+		return -EIO;
+	}
+
+	len -= sizeof(symlink_buf->InodeType);
 
 	if (le64_to_cpu(symlink_buf->InodeType) != NFS_SPECFILE_LNK) {
 		cifs_dbg(VFS, "%lld not a supported symlink type\n",
-- 
2.40.1

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Sasha Levin]

[ Sasha's backport helper bot ]

Hi,

Found matching upstream commit: e2a8910af01653c1c268984855629d71fb81f404

WARNING: Author mismatch between patch and found commit:
Backport author: Mahmoud Adam <mngyadam@amazon.com>
Commit author: Pali Rohár <pali@kernel.org>


Status in newer kernel trees:
6.12.y | Present (exact SHA1)

Note: The patch differs from the upstream commit:
---
--- -	2024-11-22 09:47:45.236983679 -0500
+++ /tmp/tmp.lZ1aBV8tvg	2024-11-22 09:47:45.226445426 -0500
@@ -1,3 +1,5 @@
+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.
@@ -18,48 +20,32 @@
 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>
 ---
- fs/smb/client/reparse.c | 15 ++++++++++++++-
- 1 file changed, 14 insertions(+), 1 deletion(-)
+This fixes CVE-2024-49996, and applies cleanly on 5.4->6.1, 6.6 and
+later already has the fix.
+ fs/smb/client/smb2ops.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
 
-diff --git a/fs/smb/client/reparse.c b/fs/smb/client/reparse.c
-index 3b48a093cfb1f..8ea7a848aa393 100644
---- a/fs/smb/client/reparse.c
-+++ b/fs/smb/client/reparse.c
-@@ -320,9 +320,16 @@ static int parse_reparse_posix(struct reparse_posix_data *buf,
- 	unsigned int len;
- 	u64 type;
+diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
+index d1e5ff9a3cd39..fcfbc096924a8 100644
+--- a/fs/smb/client/smb2ops.c
++++ b/fs/smb/client/smb2ops.c
+@@ -2897,6 +2897,12 @@ parse_reparse_posix(struct reparse_posix_data *symlink_buf,
  
-+	len = le16_to_cpu(buf->ReparseDataLength);
-+	if (len < sizeof(buf->InodeType)) {
+ 	/* See MS-FSCC 2.1.2.6 for the 'NFS' style reparse tags */
+ 	len = le16_to_cpu(symlink_buf->ReparseDataLength);
++	if (len < sizeof(symlink_buf->InodeType)) {
 +		cifs_dbg(VFS, "srv returned malformed nfs buffer\n");
 +		return -EIO;
 +	}
 +
-+	len -= sizeof(buf->InodeType);
-+
- 	switch ((type = le64_to_cpu(buf->InodeType))) {
- 	case NFS_SPECFILE_LNK:
--		len = le16_to_cpu(buf->ReparseDataLength);
- 		data->symlink_target = cifs_strndup_from_utf16(buf->DataBuffer,
- 							       len, true,
- 							       cifs_sb->local_nls);
-@@ -482,12 +489,18 @@ bool cifs_reparse_point_to_fattr(struct cifs_sb_info *cifs_sb,
- 	u32 tag = data->reparse.tag;
++	len -= sizeof(symlink_buf->InodeType);
  
- 	if (tag == IO_REPARSE_TAG_NFS && buf) {
-+		if (le16_to_cpu(buf->ReparseDataLength) < sizeof(buf->InodeType))
-+			return false;
- 		switch (le64_to_cpu(buf->InodeType)) {
- 		case NFS_SPECFILE_CHR:
-+			if (le16_to_cpu(buf->ReparseDataLength) != sizeof(buf->InodeType) + 8)
-+				return false;
- 			fattr->cf_mode |= S_IFCHR;
- 			fattr->cf_rdev = reparse_mkdev(buf->DataBuffer);
- 			break;
- 		case NFS_SPECFILE_BLK:
-+			if (le16_to_cpu(buf->ReparseDataLength) != sizeof(buf->InodeType) + 8)
-+				return false;
- 			fattr->cf_mode |= S_IFBLK;
- 			fattr->cf_rdev = reparse_mkdev(buf->DataBuffer);
- 			break;
+ 	if (le64_to_cpu(symlink_buf->InodeType) != NFS_SPECFILE_LNK) {
+ 		cifs_dbg(VFS, "%lld not a supported symlink type\n",
+-- 
+2.40.1
+
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-6.12.y       |  Failed     |  N/A       |
| stable/linux-6.11.y       |  Failed     |  N/A       |
| stable/linux-6.6.y        |  Failed     |  N/A       |
| stable/linux-6.1.y        |  Success    |  Success   |
| stable/linux-5.15.y       |  Failed     |  N/A       |
| stable/linux-5.10.y       |  Failed     |  N/A       |
| stable/linux-5.4.y        |  Failed     |  N/A       |
| stable/linux-4.19.y       |  Failed     |  N/A       |

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Mahmoud Adam]

Sasha Levin <sashal@kernel.org> writes:

> | Branch                    | Patch Apply | Build Test |
> |---------------------------|-------------|------------|
> | stable/linux-6.12.y       |  Failed     |  N/A       |
> | stable/linux-6.11.y       |  Failed     |  N/A       |
> | stable/linux-6.6.y        |  Failed     |  N/A       |
> | stable/linux-6.1.y        |  Success    |  Success   |
> | stable/linux-5.15.y       |  Failed     |  N/A       |
> | stable/linux-5.10.y       |  Failed     |  N/A       |
> | stable/linux-5.4.y        |  Failed     |  N/A       |
> | stable/linux-4.19.y       |  Failed     |  N/A       |

Ah Yes, for 5.15 and less, it should be patched to fs/cifs/smb2ops.c
instead of fs/smb/client/smb2ops.c, I'll send a separate patch for them.

-MNAdam

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Pali Rohár]

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?

>  fs/smb/client/smb2ops.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
> index d1e5ff9a3cd39..fcfbc096924a8 100644
> --- a/fs/smb/client/smb2ops.c
> +++ b/fs/smb/client/smb2ops.c
> @@ -2897,6 +2897,12 @@ parse_reparse_posix(struct reparse_posix_data *symlink_buf,
>  
>  	/* See MS-FSCC 2.1.2.6 for the 'NFS' style reparse tags */
>  	len = le16_to_cpu(symlink_buf->ReparseDataLength);
> +	if (len < sizeof(symlink_buf->InodeType)) {
> +		cifs_dbg(VFS, "srv returned malformed nfs buffer\n");
> +		return -EIO;
> +	}
> +
> +	len -= sizeof(symlink_buf->InodeType);
>  
>  	if (le64_to_cpu(symlink_buf->InodeType) != NFS_SPECFILE_LNK) {
>  		cifs_dbg(VFS, "%lld not a supported symlink type\n",
> -- 
> 2.40.1
> 

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[kernel test robot]

Hi,

Thanks for your patch.

FYI: kernel test robot notices the stable kernel rule is not satisfied.

The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1

Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree.
Subject: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points
Link: https://lore.kernel.org/stable/20241122134410.124563-1-mngyadam%40amazon.com

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Mahmoud Adam]

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

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Pali Rohár]

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.

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Greg KH]

On Sun, Dec 01, 2024 at 01:37:35PM +0100, Pali Rohár wrote:
> 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.

We have decided not to do that to prevent spamming
maintainers/developers with even more things that they just don't want
to care about.  Remember, we assign about 50 CVEs a week.  If you wish
to see all CVEs assigned to parts of the kernel that you maintain, just
subscribe to the cve-announce mailing list or use a tool like `lei` to
provide a feed of stuff just that you care about.

thanks,

greg k-h

Re: [PATCH] cifs: Fix buffer overflow when parsing NFS reparse points

[Pali Rohár]

On Sunday 01 December 2024 13:44:15 Greg KH wrote:
> On Sun, Dec 01, 2024 at 01:37:35PM +0100, Pali Rohár wrote:
> > 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.
> 
> We have decided not to do that to prevent spamming
> maintainers/developers with even more things that they just don't want
> to care about.  Remember, we assign about 50 CVEs a week.  If you wish
> to see all CVEs assigned to parts of the kernel that you maintain, just
> subscribe to the cve-announce mailing list or use a tool like `lei` to
> provide a feed of stuff just that you care about.
> 
> thanks,
> 
> greg k-h

Ok, fair enough. I did not know about such high number. It is better
than to really not spam developers about it.

I was just surprised about MNAdam email as CCed me that what happened.