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",
[ 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 |
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
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
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
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.
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
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.
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#opti...
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
kernel test robot -
Mahmoud Adam -
Pali Rohár -
Sasha Levin