summaryrefslogtreecommitdiff
path: root/crypto
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2011-12-01 20:23:34 -0500
committerSteve French <smfrench@gmail.com>2011-12-08 22:04:47 -0600
commit7023676f9ee851d94f0942e879243fc1f9081c47 (patch)
tree6aac4d2bbaae57306fa320beb4282c380171a8e2 /crypto
parent95edcff497b126a3f3e079e94b20fe2ca7e5a63d (diff)
downloadlinux-3.10-7023676f9ee851d94f0942e879243fc1f9081c47.tar.gz
linux-3.10-7023676f9ee851d94f0942e879243fc1f9081c47.tar.bz2
linux-3.10-7023676f9ee851d94f0942e879243fc1f9081c47.zip
cifs: check for NULL last_entry before calling cifs_save_resume_key
Prior to commit eaf35b1, cifs_save_resume_key had some NULL pointer checks at the top. It turns out that at least one of those NULL pointer checks is needed after all. When the LastNameOffset in a FIND reply appears to be beyond the end of the buffer, CIFSFindFirst and CIFSFindNext will set srch_inf.last_entry to NULL. Since eaf35b1, the code will now oops in this situation. Fix this by having the callers check for a NULL last entry pointer before calling cifs_save_resume_key. No change is needed for the call site in cifs_readdir as it's not reachable with a NULL current_entry pointer. This should fix: https://bugzilla.redhat.com/show_bug.cgi?id=750247 Cc: stable@vger.kernel.org Cc: Christoph Hellwig <hch@infradead.org> Reported-by: Adam G. Metzler <adamgmetzler@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions