<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/fs/cifs, branch linux-4.18.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-4.18.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-4.18.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2018-11-13T19:12:45+00:00</updated>
<entry>
<title>smb3: on kerberos mount if server doesn't specify auth type use krb5</title>
<updated>2018-11-13T19:12:45+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2018-10-28T18:13:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fa4aec4d1e6542bfdaa51f332e03c00e1ef230e2'/>
<id>urn:sha1:fa4aec4d1e6542bfdaa51f332e03c00e1ef230e2</id>
<content type='text'>
commit 926674de6705f0f1dbf29a62fd758d0977f535d6 upstream.

Some servers (e.g. Azure) do not include a spnego blob in the SMB3
negotiate protocol response, so on kerberos mounts ("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.

Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Reviewed-by: Ronnie Sahlberg &lt;lsahlber@redhat.com&gt;
CC: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>smb3: do not attempt cifs operation in smb3 query info error path</title>
<updated>2018-11-13T19:12:45+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2018-10-19T05:45:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e8c4202e4b1680570a0736e289964a7dcfd45a41'/>
<id>urn:sha1:e8c4202e4b1680570a0736e289964a7dcfd45a41</id>
<content type='text'>
commit 1e77a8c204c9d1b655c61751b8ad0fde22421dbb upstream.

If backupuid mount option is sent, we can incorrectly retry
(on access denied on query info) with a cifs (FindFirst) operation
on an smb3 mount which causes the server to force the session close.

We set backup intent on open so no need for this fallback.

See kernel bugzilla 201435

Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
CC: Stable &lt;stable@vger.kernel.org&gt;
Reviewed-by: Ronnie Sahlberg &lt;lsahlber@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>smb3: allow stats which track session and share reconnects to be reset</title>
<updated>2018-11-13T19:12:45+00:00</updated>
<author>
<name>Steve French</name>
<email>stfrench@microsoft.com</email>
</author>
<published>2018-09-16T04:04:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=278223e1fa26e3580ab9bf2ffcdfb96fd57e24dd'/>
<id>urn:sha1:278223e1fa26e3580ab9bf2ffcdfb96fd57e24dd</id>
<content type='text'>
commit 2c887635cd6ab3af619dc2be94e5bf8f2e172b78 upstream.

Currently, "echo 0 &gt; /proc/fs/cifs/Stats" resets all of the stats
except the session and share reconnect counts.  Fix it to
reset those as well.

CC: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Reviewed-by: Aurelien Aptel &lt;aaptel@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>smb2: fix missing files in root share directory listing</title>
<updated>2018-10-10T06:56:07+00:00</updated>
<author>
<name>Aurelien Aptel</name>
<email>aaptel@suse.com</email>
</author>
<published>2018-05-17T14:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8cdcd02d998590fe4ceb7a0eadb33acaef335a88'/>
<id>urn:sha1:8cdcd02d998590fe4ceb7a0eadb33acaef335a88</id>
<content type='text'>
commit 0595751f267994c3c7027377058e4185b3a28e75 upstream.

When mounting a Windows share that is the root of a drive (eg. C$)
the server does not return . and .. directory entries. This results in
the smb2 code path erroneously skipping the 2 first entries.

Pseudo-code of the readdir() code path:

cifs_readdir(struct file, struct dir_context)
    initiate_cifs_search            &lt;-- if no reponse cached yet
        server-&gt;ops-&gt;query_dir_first

    dir_emit_dots
        dir_emit                    &lt;-- adds "." and ".." if we're at pos=0

    find_cifs_entry
        initiate_cifs_search        &lt;-- if pos &lt; start of current response
                                         (restart search)
        server-&gt;ops-&gt;query_dir_next &lt;-- if pos &gt; end of current response
                                         (fetch next search res)

    for(...)                        &lt;-- loops over cur response entries
                                          starting at pos
        cifs_filldir                &lt;-- skip . and .., emit entry
            cifs_fill_dirent
            dir_emit
	pos++

A) dir_emit_dots() always adds . &amp; ..
   and sets the current dir pos to 2 (0 and 1 are done).

Therefore we always want the index_to_find to be 2 regardless of if
the response has . and ..

B) smb1 code initializes index_of_last_entry with a +2 offset

  in cifssmb.c CIFSFindFirst():
		psrch_inf-&gt;index_of_last_entry = 2 /* skip . and .. */ +
			psrch_inf-&gt;entries_in_buffer;

Later in find_cifs_entry() we want to find the next dir entry at pos=2
as a result of (A)

	first_entry_in_buffer = cfile-&gt;srch_inf.index_of_last_entry -
					cfile-&gt;srch_inf.entries_in_buffer;

This var is the dir pos that the first entry in the buffer will
have therefore it must be 2 in the first call.

If we don't offset index_of_last_entry by 2 (like in (B)),
first_entry_in_buffer=0 but we were instructed to get pos=2 so this
code in find_cifs_entry() skips the 2 first which is ok for non-root
shares, as it skips . and .. from the response but is not ok for root
shares where the 2 first are actual files

		pos_in_buf = index_to_find - first_entry_in_buffer;
                // pos_in_buf=2
		// we skip 2 first response entries :(
		for (i = 0; (i &lt; (pos_in_buf)) &amp;&amp; (cur_ent != NULL); i++) {
			/* go entry by entry figuring out which is first */
			cur_ent = nxt_dir_entry(cur_ent, end_of_smb,
						cfile-&gt;srch_inf.info_level);
		}

C) cifs_filldir() skips . and .. so we can safely ignore them for now.

Sample program:

int main(int argc, char **argv)
{
	const char *path = argc &gt;= 2 ? argv[1] : ".";
	DIR *dh;
	struct dirent *de;

	printf("listing path &lt;%s&gt;\n", path);
	dh = opendir(path);
	if (!dh) {
		printf("opendir error %d\n", errno);
		return 1;
	}

	while (1) {
		de = readdir(dh);
		if (!de) {
			if (errno) {
				printf("readdir error %d\n", errno);
				return 1;
			}
			printf("end of listing\n");
			break;
		}
		printf("off=%lu &lt;%s&gt;\n", de-&gt;d_off, de-&gt;d_name);
	}

	return 0;
}

Before the fix with SMB1 on root shares:

&lt;.&gt;            off=1
&lt;..&gt;           off=2
&lt;$Recycle.Bin&gt; off=3
&lt;bootmgr&gt;      off=4

and on non-root shares:

&lt;.&gt;    off=1
&lt;..&gt;   off=4  &lt;-- after adding .., the offsets jumps to +2 because
&lt;2536&gt; off=5       we skipped . and .. from response buffer (C)
&lt;411&gt;  off=6       but still incremented pos
&lt;file&gt; off=7
&lt;fsx&gt;  off=8

Therefore the fix for smb2 is to mimic smb1 behaviour and offset the
index_of_last_entry by 2.

Test results comparing smb1 and smb2 before/after the fix on root
share, non-root shares and on large directories (ie. multi-response
dir listing):

PRE FIX
=======
pre-1-root VS pre-2-root:
        ERR pre-2-root is missing [bootmgr, $Recycle.Bin]
pre-1-nonroot VS pre-2-nonroot:
        OK~ same files, same order, different offsets
pre-1-nonroot-large VS pre-2-nonroot-large:
        OK~ same files, same order, different offsets

POST FIX
========
post-1-root VS post-2-root:
        OK same files, same order, same offsets
post-1-nonroot VS post-2-nonroot:
        OK same files, same order, same offsets
post-1-nonroot-large VS post-2-nonroot-large:
        OK same files, same order, same offsets

REGRESSION?
===========
pre-1-root VS post-1-root:
        OK same files, same order, same offsets
pre-1-nonroot VS post-1-nonroot:
        OK same files, same order, same offsets

BugLink: https://bugzilla.samba.org/show_bug.cgi?id=13107
Signed-off-by: Aurelien Aptel &lt;aaptel@suse.com&gt;
Signed-off-by: Paulo Alcantara &lt;palcantara@suse.deR&gt;
Reviewed-by: Ronnie Sahlberg &lt;lsahlber@redhat.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
CC: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cifs: read overflow in is_valid_oplock_break()</title>
<updated>2018-10-10T06:56:03+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-09-06T09:47:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=80e4d9a5137669a5508f94a1674d960d0edc864b'/>
<id>urn:sha1:80e4d9a5137669a5508f94a1674d960d0edc864b</id>
<content type='text'>
[ Upstream commit 097f5863b1a0c9901f180bbd56ae7d630655faaa ]

We need to verify that the "data_offset" is within bounds.

Reported-by: Dr Silvio Cesare of InfoSect &lt;silvio.cesare@gmail.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Reviewed-by: Aurelien Aptel &lt;aaptel@suse.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fs/cifs: suppress a string overflow warning</title>
<updated>2018-10-10T06:56:01+00:00</updated>
<author>
<name>Stephen Rothwell</name>
<email>sfr@canb.auug.org.au</email>
</author>
<published>2018-09-03T03:15:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3a035b70eb920e584aedf6bc1a960af81834f74c'/>
<id>urn:sha1:3a035b70eb920e584aedf6bc1a960af81834f74c</id>
<content type='text'>
[ Upstream commit bcfb84a996f6fa90b5e6e2954b2accb7a4711097 ]

A powerpc build of cifs with gcc v8.2.0 produces this warning:

fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
   strncpy(pSMB-&gt;DialectsArray+count, protocols[i].name, 16);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since we are already doing a strlen() on the source, change the strncpy
to a memcpy().

Signed-off-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fs/cifs: don't translate SFM_SLASH (U+F026) to backslash</title>
<updated>2018-10-10T06:55:55+00:00</updated>
<author>
<name>Jon Kuhn</name>
<email>jkuhn@barracuda.com</email>
</author>
<published>2018-07-09T14:33:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=05166cf09a6e71a7dcda746294e138957f5a93c0'/>
<id>urn:sha1:05166cf09a6e71a7dcda746294e138957f5a93c0</id>
<content type='text'>
[ Upstream commit c15e3f19a6d5c89b1209dc94b40e568177cb0921 ]

When a Mac client saves an item containing a backslash to a file server
the backslash is represented in the CIFS/SMB protocol as as U+F026.
Before this change, listing a directory containing an item with a
backslash in its name will return that item with the backslash
represented with a true backslash character (U+005C) because
convert_sfm_character mapped U+F026 to U+005C when interpretting the
CIFS/SMB protocol response.  However, attempting to open or stat the
path using a true backslash will result in an error because
convert_to_sfm_char does not map U+005C back to U+F026 causing the
CIFS/SMB request to be made with the backslash represented as U+005C.

This change simply prevents the U+F026 to U+005C conversion from
happenning.  This is analogous to how the code does not do any
translation of UNI_SLASH (U+F000).

Signed-off-by: Jon Kuhn &lt;jkuhn@barracuda.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cifs: integer overflow in in SMB2_ioctl()</title>
<updated>2018-09-26T06:39:34+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-09-10T11:12:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f63dbd23e8a7d1d342c6dbe7033039326da2a5ed'/>
<id>urn:sha1:f63dbd23e8a7d1d342c6dbe7033039326da2a5ed</id>
<content type='text'>
commit 2d204ee9d671327915260071c19350d84344e096 upstream.

The "le32_to_cpu(rsp-&gt;OutputOffset) + *plen" addition can overflow and
wrap around to a smaller value which looks like it would lead to an
information leak.

Fixes: 4a72dafa19ba ("SMB2 FSCTL and IOCTL worker function")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Reviewed-by: Aurelien Aptel &lt;aaptel@suse.com&gt;
CC: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>CIFS: fix wrapping bugs in num_entries()</title>
<updated>2018-09-26T06:39:33+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-09-06T09:48:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6565bd3e63d393fecf9d549dac20b1889810e02f'/>
<id>urn:sha1:6565bd3e63d393fecf9d549dac20b1889810e02f</id>
<content type='text'>
commit 56446f218af1133c802dad8e9e116f07f381846c upstream.

The problem is that "entryptr + next_offset" and "entryptr + len + size"
can wrap.  I ended up changing the type of "entryptr" because it makes
the math easier when we don't have to do so much casting.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Reviewed-by: Aurelien Aptel &lt;aaptel@suse.com&gt;
Reviewed-by: Pavel Shilovsky &lt;pshilov@microsoft.com&gt;
CC: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cifs: prevent integer overflow in nxt_dir_entry()</title>
<updated>2018-09-26T06:39:33+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-09-06T09:47:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bf1c05755d450ae2b3c8d4b703ff4ebed4c6c53b'/>
<id>urn:sha1:bf1c05755d450ae2b3c8d4b703ff4ebed4c6c53b</id>
<content type='text'>
commit 8ad8aa353524d89fa2e09522f3078166ff78ec42 upstream.

The "old_entry + le32_to_cpu(pDirInfo-&gt;NextEntryOffset)" can wrap
around so I have added a check for integer overflow.

Reported-by: Dr Silvio Cesare of InfoSect &lt;silvio.cesare@gmail.com&gt;
Reviewed-by: Ronnie Sahlberg &lt;lsahlber@redhat.com&gt;
Reviewed-by: Aurelien Aptel &lt;aaptel@suse.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
CC: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
