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