<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/cifs, branch linux-3.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-04-27T07:30:28Z</updated>
<entry>
<title>fix incorrect error code mapping for OBJECTID_NOT_FOUND</title>
<updated>2019-04-27T07:30:28Z</updated>
<author>
<name>Steve French</name>
</author>
<published>2019-03-17T20:58:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=15863a0dfa9dad1f421c0e037221f1ad2f63b945'/>
<id>urn:sha1:15863a0dfa9dad1f421c0e037221f1ad2f63b945</id>
<content type='text'>
[ Upstream commit 85f9987b236cf46e06ffdb5c225cf1f3c0acb789 ]

It was mapped to EIO which can be confusing when user space
queries for an object GUID for an object for which the server
file system doesn't support (or hasn't saved one).

As Amir Goldstein suggested this is similar to ENOATTR
(equivalently ENODATA in Linux errno definitions) so
changing NT STATUS code mapping for OBJECTID_NOT_FOUND
to ENODATA.

Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
CC: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cifs: Fix NULL pointer dereference of devname</title>
<updated>2019-04-27T07:30:21Z</updated>
<author>
<name>Yao Liu</name>
</author>
<published>2019-01-28T11:47:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5213ffd0b6fc8012f099468991510447977eaa03'/>
<id>urn:sha1:5213ffd0b6fc8012f099468991510447977eaa03</id>
<content type='text'>
[ Upstream commit 68e2672f8fbd1e04982b8d2798dd318bf2515dd2 ]

There is a NULL pointer dereference of devname in strspn()

The oops looks something like:

  CIFS: Attempting to mount (null)
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
  ...
  RIP: 0010:strspn+0x0/0x50
  ...
  Call Trace:
   ? cifs_parse_mount_options+0x222/0x1710 [cifs]
   ? cifs_get_volume_info+0x2f/0x80 [cifs]
   cifs_setup_volume_info+0x20/0x190 [cifs]
   cifs_get_volume_info+0x50/0x80 [cifs]
   cifs_smb3_do_mount+0x59/0x630 [cifs]
   ? ida_alloc_range+0x34b/0x3d0
   cifs_do_mount+0x11/0x20 [cifs]
   mount_fs+0x52/0x170
   vfs_kern_mount+0x6b/0x170
   do_mount+0x216/0xdc0
   ksys_mount+0x83/0xd0
   __x64_sys_mount+0x25/0x30
   do_syscall_64+0x65/0x220
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fix this by adding a NULL check on devname in cifs_parse_devname()

Signed-off-by: Yao Liu &lt;yotta.liu@ucloud.cn&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cifs: use correct format characters</title>
<updated>2019-04-27T07:30:20Z</updated>
<author>
<name>Louis Taylor</name>
</author>
<published>2019-02-27T22:25:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=712516d97ee0a2ec35194c903b63716d06181480'/>
<id>urn:sha1:712516d97ee0a2ec35194c903b63716d06181480</id>
<content type='text'>
[ Upstream commit 259594bea574e515a148171b5cd84ce5cbdc028a ]

When compiling with -Wformat, clang emits the following warnings:

fs/cifs/smb1ops.c:312:20: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
                         tgt_total_cnt, total_in_tgt);
                                        ^~~~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:289:4: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
                 ref-&gt;flags, ref-&gt;server_type);
                 ^~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:289:16: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
                 ref-&gt;flags, ref-&gt;server_type);
                             ^~~~~~~~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:291:4: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
                 ref-&gt;ref_flag, ref-&gt;path_consumed);
                 ^~~~~~~~~~~~~

fs/cifs/cifs_dfs_ref.c:291:19: warning: format specifies type 'short'
but the argument has type 'int' [-Wformat]
                 ref-&gt;ref_flag, ref-&gt;path_consumed);
                                ^~~~~~~~~~~~~~~~~~
The types of these arguments are unconditionally defined, so this patch
updates the format character to the correct ones for ints and unsigned
ints.

Link: https://github.com/ClangBuiltLinux/linux/issues/378

Signed-off-by: Louis Taylor &lt;louis@kragniz.eu&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>CIFS: Fix read after write for files with read caching</title>
<updated>2019-03-23T07:19:00Z</updated>
<author>
<name>Pavel Shilovsky</name>
</author>
<published>2019-03-05T01:48:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ed6d71db0ea04d666b19901faa6ce0f1967795d6'/>
<id>urn:sha1:ed6d71db0ea04d666b19901faa6ce0f1967795d6</id>
<content type='text'>
commit 6dfbd84684700cb58b34e8602c01c12f3d2595c8 upstream.

When we have a READ lease for a file and have just issued a write
operation to the server we need to purge the cache and set oplock/lease
level to NONE to avoid reading stale data. Currently we do that
only if a write operation succedeed thus not covering cases when
a request was sent to the server but a negative error code was
returned later for some other reasons (e.g. -EIOCBQUEUED or -EINTR).
Fix this by turning off caching regardless of the error code being
returned.

The patches fixes generic tests 075 and 112 from the xfs-tests.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Pavel Shilovsky &lt;pshilov@microsoft.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&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>cifs: fix computation for MAX_SMB2_HDR_SIZE</title>
<updated>2019-03-23T07:18:56Z</updated>
<author>
<name>Ronnie Sahlberg</name>
</author>
<published>2019-01-29T02:46:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4b3cc96fa270c9a1d943d725259f67ddb413a8b5'/>
<id>urn:sha1:4b3cc96fa270c9a1d943d725259f67ddb413a8b5</id>
<content type='text'>
[ Upstream commit 58d15ed1203f4d858c339ea4d7dafa94bd2a56d3 ]

The size of the fixed part of the create response is 88 bytes not 56.

Signed-off-by: Ronnie Sahlberg &lt;lsahlber@redhat.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Reviewed-by: Pavel Shilovsky &lt;pshilov@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cifs: Limit memory used by lock request calls to a page</title>
<updated>2019-02-20T09:09:10Z</updated>
<author>
<name>Ross Lagerwall</name>
</author>
<published>2019-01-08T18:30:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=32f501297e0ca4d0c290aaf4da9993def414fff5'/>
<id>urn:sha1:32f501297e0ca4d0c290aaf4da9993def414fff5</id>
<content type='text'>
[ Upstream commit 92a8109e4d3a34fb6b115c9098b51767dc933444 ]

The code tries to allocate a contiguous buffer with a size supplied by
the server (maxBuf). This could fail if memory is fragmented since it
results in high order allocations for commonly used server
implementations. It is also wasteful since there are probably
few locks in the usual case. Limit the buffer to be no larger than a
page to avoid memory allocation failures due to fragmentation.

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cifs: check ntwrk_buf_start for NULL before dereferencing it</title>
<updated>2019-02-20T09:09:02Z</updated>
<author>
<name>Ronnie Sahlberg</name>
</author>
<published>2018-12-12T22:06:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c20306485299080337731091c644da997278688c'/>
<id>urn:sha1:c20306485299080337731091c644da997278688c</id>
<content type='text'>
[ Upstream commit 59a63e479ce36a3f24444c3a36efe82b78e4a8e0 ]

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 &lt;lsahlber@redhat.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>CIFS: Do not count -ENODATA as failure for query directory</title>
<updated>2019-02-06T16:34:53Z</updated>
<author>
<name>Pavel Shilovsky</name>
</author>
<published>2019-01-26T20:21:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3a4b0cbdca0665a5e2935ad686c585945247c5dd'/>
<id>urn:sha1:3a4b0cbdca0665a5e2935ad686c585945247c5dd</id>
<content type='text'>
commit 8e6e72aeceaaed5aeeb1cb43d3085de7ceb14f79 upstream.

Signed-off-by: Pavel Shilovsky &lt;pshilov@microsoft.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: Fix possible hang during async MTU reads and writes</title>
<updated>2019-02-06T16:34:52Z</updated>
<author>
<name>Pavel Shilovsky</name>
</author>
<published>2019-01-17T16:21:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e2a07b39388ff5852fc85c3306dff9aa195648a8'/>
<id>urn:sha1:e2a07b39388ff5852fc85c3306dff9aa195648a8</id>
<content type='text'>
commit acc58d0bab55a50e02c25f00bd6a210ee121595f upstream.

When doing MTU i/o we need to leave some credits for
possible reopen requests and other operations happening
in parallel. Currently we leave 1 credit which is not
enough even for reopen only: we need at least 2 credits
if durable handle reconnect fails. Also there may be
other operations at the same time including compounding
ones which require 3 credits at a time each. Fix this
by leaving 8 credits which is big enough to cover most
scenarios.

Was able to reproduce this when server was configured
to give out fewer credits than usual.

The proper fix would be to reconnect a file handle first
and then obtain credits for an MTU request but this leads
to bigger code changes and should happen in other patches.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Pavel Shilovsky &lt;pshilov@microsoft.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cifs: Fix potential OOB access of lock element array</title>
<updated>2019-01-26T08:44:23Z</updated>
<author>
<name>Ross Lagerwall</name>
</author>
<published>2019-01-08T18:30:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ac72ab69de6686c9a4d65f0e44f13cdfb6255086'/>
<id>urn:sha1:ac72ab69de6686c9a4d65f0e44f13cdfb6255086</id>
<content type='text'>
commit b9a74cde94957d82003fb9f7ab4777938ca851cd upstream.

If maxBuf is small but non-zero, it could result in a zero sized lock
element array which we would then try and access OOB.

Signed-off-by: Ross Lagerwall &lt;ross.lagerwall@citrix.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>
