First published: Wed Aug 24 2011(Updated: )
The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. Fix this by making the name_len an unsigned value in CIFSFindNext. <a href="http://www.spinics.net/lists/linux-cifs/msg03950.html">http://www.spinics.net/lists/linux-cifs/msg03950.html</a> Acknowledgements: Red Hat would like to thank Darren Lavender for reporting this issue.
Affected Software | Affected Version | How to fix |
---|---|---|
Linux CIFS |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
The severity of REDHAT-BUG-732869 is classified as moderate.
To fix REDHAT-BUG-732869, you need to apply the recommended patches provided in the errata for your affected version of Linux CIFS.
REDHAT-BUG-732869 affects systems running the Linux CIFS client.
REDHAT-BUG-732869 is caused by a mismatch between signed and unsigned integer types in the handling of the resume_name_len variable.
A temporary workaround for REDHAT-BUG-732869 may involve limiting the size of data sent from the server.