BMC/Intel-BMC/linux.git/fs/cifs/readdir.c, branch dev-5.2

cifs: check ntwrk_buf_start for NULL before dereferencing it

2018-12-24T04:41:31+00:00

RHBZ: 1021460 There is an issue where when multiple threads open/close the same directory ntwrk_buf_start might end up being NULL, causing the call to smbCalcSize later to oops with a NULL deref. The real bug is why this happens and why this can become NULL for an open cfile, which should not be allowed. This patch tries to avoid a oops until the time when we fix the underlying issue. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French

cifs: prevent integer overflow in nxt_dir_entry()

2018-09-12T14:27:57+00:00

The "old_entry + le32_to_cpu(pDirInfo->NextEntryOffset)" can wrap around so I have added a check for integer overflow. Reported-by: Dr Silvio Cesare of InfoSect Reviewed-by: Ronnie Sahlberg Reviewed-by: Aurelien Aptel Signed-off-by: Dan Carpenter Signed-off-by: Steve French CC: Stable

cifs: update calc_size to take a server argument

2018-05-27T22:56:35+00:00

and change the smb2 version to take heder_preamble_size into account instead of hardcoding it as 4 bytes. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French

cifs: initialize file_info_lock

2017-01-14T20:58:29+00:00

Reviewed-by: Jeff Layton CC: Stable file_info_lock is not initalized in initiate_cifs_search(), leading to the following splat after a simple "mount.cifs ... dir && ls dir/": BUG: spinlock bad magic on CPU#0, ls/486 lock: 0xffff880009301110, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 0 PID: 486 Comm: ls Not tainted 4.9.0 #27 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ffffc900042f3db0 ffffffff81327533 0000000000000000 ffff880009301110 ffffc900042f3dd0 ffffffff810baf75 ffff880009301110 ffffffff817ae077 ffffc900042f3df0 ffffffff810baff6 ffff880009301110 ffff880008d69900 Call Trace: [] dump_stack+0x65/0x92 [] spin_dump+0x85/0xe0 [] spin_bug+0x26/0x30 [] do_raw_spin_lock+0xe9/0x130 [] _raw_spin_lock+0x1f/0x30 [] cifs_closedir+0x4d/0x100 [] __fput+0x5d/0x160 [] ____fput+0xe/0x10 [] task_work_run+0x7e/0xa0 [] exit_to_usermode_loop+0x92/0xa0 [] syscall_return_slowpath+0x49/0x50 [] entry_SYSCALL_64_fastpath+0xa7/0xa9 Fixes: 3afca265b5f53a0 ("Clarify locking of cifs file and tcon structures and make more granular") Signed-off-by: Rabin Vincent Signed-off-by: Steve French

Clarify locking of cifs file and tcon structures and make more granular

2016-10-12T17:08:32+00:00

Remove the global file_list_lock to simplify cifs/smb3 locking and have spinlocks that more closely match the information they are protecting. Add new tcon->open_file_lock and file->file_info_lock spinlocks. Locks continue to follow a heirachy, cifs_socket --> cifs_ses --> cifs_tcon --> cifs_file where global tcp_ses_lock still protects socket and cifs_ses, while the the newer locks protect the lower level structure's information (tcon and cifs_file respectively). CC: Stable Signed-off-by: Steve French Signed-off-by: Pavel Shilovsky Reviewed-by: Aurelien Aptel Reviewed-by: Germano Percossi

cifs: Use file_dentry()

2016-05-17T19:09:33+00:00

CIFS may be used as lower layer of overlayfs and accessing f_path.dentry can lead to a crash. Fix by replacing direct access of file->f_path.dentry with the file_dentry() accessor, which will always return a native object. Signed-off-by: Goldwyn Rodrigues Acked-by: Shirish Pargaonkar Signed-off-by: Steve French

cifs: switch to ->iterate_shared()

2016-05-02T23:49:31+00:00

Signed-off-by: Al Viro

don't bother with ->d_inode->i_sb - it's always equal to ->d_sb

2016-04-10T21:11:51+00:00

... and neither can ever be NULL Signed-off-by: Al Viro

cifs_dbg() outputs an uninitialized buffer in cifs_readdir()

2016-01-14T20:45:49+00:00

In some cases tmp_bug can be not filled in cifs_filldir and stay uninitialized, therefore its printk with "%s" modifier can leak content of kernelspace memory. If old content of this buffer does not contain '\0' access bejond end of allocated object can crash the host. Signed-off-by: Vasily Averin Signed-off-by: Steve French CC: Stable

fs: Drop unlikely before IS_ERR(_OR_NULL)

2015-09-29T13:13:58+00:00

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Signed-off-by: Viresh Kumar Reviewed-by: Jeff Layton Reviewed-by: David Howells Reviewed-by: Steve French Signed-off-by: Jiri Kosina