<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/fs, branch v4.17.5</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.17.5</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v4.17.5'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2018-07-03T09:27:09+00:00</updated>
<entry>
<title>udf: Detect incorrect directory size</title>
<updated>2018-07-03T09:27:09+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2018-06-13T10:09:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=238e2637c64123aadb7ab6c1095ad23593b65e3f'/>
<id>urn:sha1:238e2637c64123aadb7ab6c1095ad23593b65e3f</id>
<content type='text'>
commit fa65653e575fbd958bdf5fb9c4a71a324e39510d upstream.

Detect when a directory entry is (possibly partially) beyond directory
size and return EIO in that case since it means the filesystem is
corrupted. Otherwise directory operations can further corrupt the
directory and possibly also oops the kernel.

CC: Anatoly Trosinenko &lt;anatoly.trosinenko@gmail.com&gt;
CC: stable@vger.kernel.org
Reported-and-tested-by: Anatoly Trosinenko &lt;anatoly.trosinenko@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFSv4: Fix a typo in nfs41_sequence_process</title>
<updated>2018-07-03T09:27:08+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@hammerspace.com</email>
</author>
<published>2018-06-09T16:50:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=11de37bbc39c7836b119e95ea7bdd1202c0cf733'/>
<id>urn:sha1:11de37bbc39c7836b119e95ea7bdd1202c0cf733</id>
<content type='text'>
commit 995891006ccbb73c0c9c3923cf9d25c4d07ec16b upstream.

We want to compare the slot_id to the highest slot number advertised by the
server.

Fixes: 3be0f80b5fe9c ("NFSv4.1: Fix up replays of interrupted requests")
Cc: stable@vger.kernel.org # 4.15+
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFSv4: Revert commit 5f83d86cf531d ("NFSv4.x: Fix wraparound issues..")</title>
<updated>2018-07-03T09:27:08+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@hammerspace.com</email>
</author>
<published>2018-06-09T16:43:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5819c04fb70862a0a72111d95e0204f37cf5ecc0'/>
<id>urn:sha1:5819c04fb70862a0a72111d95e0204f37cf5ecc0</id>
<content type='text'>
commit fc40724fc6731d90cc7fb6d62d66135f85a33dd2 upstream.

The correct behaviour for NFSv4 sequence IDs is to wrap around
to the value 0 after 0xffffffff.
See https://tools.ietf.org/html/rfc5661#section-2.10.6.1

Fixes: 5f83d86cf531d ("NFSv4.x: Fix wraparound issues when validing...")
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFSv4: Fix possible 1-byte stack overflow in nfs_idmap_read_and_verify_message</title>
<updated>2018-07-03T09:27:08+00:00</updated>
<author>
<name>Dave Wysochanski</name>
<email>dwysocha@redhat.com</email>
</author>
<published>2018-05-29T21:47:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4c530c3b34fb53ab7293f04cb2b36f7ebb04e127'/>
<id>urn:sha1:4c530c3b34fb53ab7293f04cb2b36f7ebb04e127</id>
<content type='text'>
commit d68894800ec5712d7ddf042356f11e36f87d7f78 upstream.

In nfs_idmap_read_and_verify_message there is an incorrect sprintf '%d'
that converts the __u32 'im_id' from struct idmap_msg to 'id_str', which
is a stack char array variable of length NFS_UINT_MAXLEN == 11.
If a uid or gid value is &gt; 2147483647 = 0x7fffffff, the conversion
overflows into a negative value, for example:
crash&gt; p (unsigned) (0x80000000)
$1 = 2147483648
crash&gt; p (signed) (0x80000000)
$2 = -2147483648
The '-' sign is written to the buffer and this causes a 1 byte overflow
when the NULL byte is written, which corrupts kernel stack memory.  If
CONFIG_CC_STACKPROTECTOR_STRONG is set we see a stack-protector panic:

[11558053.616565] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa05b8a8c
[11558053.639063] CPU: 6 PID: 9423 Comm: rpc.idmapd Tainted: G        W      ------------ T 3.10.0-514.el7.x86_64 #1
[11558053.641990] Hardware name: Red Hat OpenStack Compute, BIOS 1.10.2-3.el7_4.1 04/01/2014
[11558053.644462]  ffffffff818c7bc0 00000000b1f3aec1 ffff880de0f9bd48 ffffffff81685eac
[11558053.646430]  ffff880de0f9bdc8 ffffffff8167f2b3 ffffffff00000010 ffff880de0f9bdd8
[11558053.648313]  ffff880de0f9bd78 00000000b1f3aec1 ffffffff811dcb03 ffffffffa05b8a8c
[11558053.650107] Call Trace:
[11558053.651347]  [&lt;ffffffff81685eac&gt;] dump_stack+0x19/0x1b
[11558053.653013]  [&lt;ffffffff8167f2b3&gt;] panic+0xe3/0x1f2
[11558053.666240]  [&lt;ffffffff811dcb03&gt;] ? kfree+0x103/0x140
[11558053.682589]  [&lt;ffffffffa05b8a8c&gt;] ? idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4]
[11558053.689710]  [&lt;ffffffff810855db&gt;] __stack_chk_fail+0x1b/0x30
[11558053.691619]  [&lt;ffffffffa05b8a8c&gt;] idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4]
[11558053.693867]  [&lt;ffffffffa00209d6&gt;] rpc_pipe_write+0x56/0x70 [sunrpc]
[11558053.695763]  [&lt;ffffffff811fe12d&gt;] vfs_write+0xbd/0x1e0
[11558053.702236]  [&lt;ffffffff810acccc&gt;] ? task_work_run+0xac/0xe0
[11558053.704215]  [&lt;ffffffff811fec4f&gt;] SyS_write+0x7f/0xe0
[11558053.709674]  [&lt;ffffffff816964c9&gt;] system_call_fastpath+0x16/0x1b

Fix this by calling the internally defined nfs_map_numeric_to_string()
function which properly uses '%u' to convert this __u32.  For consistency,
also replace the one other place where snprintf is called.

Signed-off-by: Dave Wysochanski &lt;dwysocha@redhat.com&gt;
Reported-by: Stephen Johnston &lt;sjohnsto@redhat.com&gt;
Fixes: cf4ab538f1516 ("NFSv4: Fix the string length returned by the idmapper")
Cc: stable@vger.kernel.org # v3.4+
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nfsd: restrict rd_maxcount to svc_max_payload in nfsd_encode_readdir</title>
<updated>2018-07-03T09:27:07+00:00</updated>
<author>
<name>Scott Mayhew</name>
<email>smayhew@redhat.com</email>
</author>
<published>2018-05-07T13:01:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2547b0da6c6990f0bd64dbfb503da003c9788151'/>
<id>urn:sha1:2547b0da6c6990f0bd64dbfb503da003c9788151</id>
<content type='text'>
commit 9c2ece6ef67e9d376f32823086169b489c422ed0 upstream.

nfsd4_readdir_rsize restricts rd_maxcount to svc_max_payload when
estimating the size of the readdir reply, but nfsd_encode_readdir
restricts it to INT_MAX when encoding the reply.  This can result in log
messages like "kernel: RPC request reserved 32896 but used 1049444".

Restrict rd_dircount similarly (no reason it should be larger than
svc_max_payload).

Signed-off-by: Scott Mayhew &lt;smayhew@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>f2fs: don't use GFP_ZERO for page caches</title>
<updated>2018-07-03T09:27:04+00:00</updated>
<author>
<name>Chao Yu</name>
<email>yuchao0@huawei.com</email>
</author>
<published>2018-04-09T12:25:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bc2bad3b87004ced2c07d185c04386eb8d8d6952'/>
<id>urn:sha1:bc2bad3b87004ced2c07d185c04386eb8d8d6952</id>
<content type='text'>
commit 81114baa835b59ed02d14aa1d67f91ea874077cd upstream.

Related to https://lkml.org/lkml/2018/4/8/661

Sometimes, we need to write meta data to new allocated block address,
then we will allocate a zeroed page in inner inode's address space, and
fill partial data in it, and leave other place with zero value which means
some fields are initial status.

There are two inner inodes (meta inode and node inode) setting __GFP_ZERO,
I have just checked them, for both of them, we can avoid using __GFP_ZERO,
and do initialization by ourselves to avoid unneeded/redundant zeroing
from mm.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Chao Yu &lt;yuchao0@huawei.com&gt;
Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>UBIFS: Fix potential integer overflow in allocation</title>
<updated>2018-07-03T09:27:03+00:00</updated>
<author>
<name>Silvio Cesare</name>
<email>silvio.cesare@gmail.com</email>
</author>
<published>2018-05-04T03:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d49a9fd028016b74f61ebbd98e41cbc899f2df93'/>
<id>urn:sha1:d49a9fd028016b74f61ebbd98e41cbc899f2df93</id>
<content type='text'>
commit 353748a359f1821ee934afc579cf04572406b420 upstream.

There is potential for the size and len fields in ubifs_data_node to be
too large causing either a negative value for the length fields or an
integer overflow leading to an incorrect memory allocation. Likewise,
when the len field is small, an integer underflow may occur.

Signed-off-by: Silvio Cesare &lt;silvio.cesare@gmail.com&gt;
Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Btrfs: fix return value on rename exchange failure</title>
<updated>2018-07-03T09:27:00+00:00</updated>
<author>
<name>Filipe Manana</name>
<email>fdmanana@suse.com</email>
</author>
<published>2018-06-11T18:24:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b3643ef1ca815808e354f2a034ee98f02cbbc9e2'/>
<id>urn:sha1:b3643ef1ca815808e354f2a034ee98f02cbbc9e2</id>
<content type='text'>
commit c5b4a50b74018b3677098151ec5f4fce07d5e6a0 upstream.

If we failed during a rename exchange operation after starting/joining a
transaction, we would end up replacing the return value, stored in the
local 'ret' variable, with the return value from btrfs_end_transaction().
So this could end up returning 0 (success) to user space despite the
operation having failed and aborted the transaction, because if there are
multiple tasks having a reference on the transaction at the time
btrfs_end_transaction() is called by the rename exchange, that function
returns 0 (otherwise it returns -EIO and not the original error value).
So fix this by not overwriting the return value on error after getting
a transaction handle.

Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT")
CC: stable@vger.kernel.org # 4.9+
Signed-off-by: Filipe Manana &lt;fdmanana@suse.com&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fuse: fix control dir setup and teardown</title>
<updated>2018-07-03T09:26:50+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2018-05-31T10:26:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dcc2f0e875c53b3ffe70859354d3048567688893'/>
<id>urn:sha1:dcc2f0e875c53b3ffe70859354d3048567688893</id>
<content type='text'>
commit 6becdb601bae2a043d7fb9762c4d48699528ea6e upstream.

syzbot is reporting NULL pointer dereference at fuse_ctl_remove_conn() [1].
Since fc-&gt;ctl_ndents is incremented by fuse_ctl_add_conn() when new_inode()
failed, fuse_ctl_remove_conn() reaches an inode-less dentry and tries to
clear d_inode(dentry)-&gt;i_private field.

Fix by only adding the dentry to the array after being fully set up.

When tearing down the control directory, do d_invalidate() on it to get rid
of any mounts that might have been added.

[1] https://syzkaller.appspot.com/bug?id=f396d863067238959c91c0b7cfc10b163638cac6
Reported-by: syzbot &lt;syzbot+32c236387d66c4516827@syzkaller.appspotmail.com&gt;
Fixes: bafa96541b25 ("[PATCH] fuse: add control filesystem")
Cc: &lt;stable@vger.kernel.org&gt; # v2.6.18
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fuse: don't keep dead fuse_conn at fuse_fill_super().</title>
<updated>2018-07-03T09:26:49+00:00</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2018-05-01T04:12:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bb086bb13b2427078b2de4ac93f10830b493e74d'/>
<id>urn:sha1:bb086bb13b2427078b2de4ac93f10830b493e74d</id>
<content type='text'>
commit 543b8f8662fe6d21f19958b666ab0051af9db21a upstream.

syzbot is reporting use-after-free at fuse_kill_sb_blk() [1].
Since sb-&gt;s_fs_info field is not cleared after fc was released by
fuse_conn_put() when initialization failed, fuse_kill_sb_blk() finds
already released fc and tries to hold the lock. Fix this by clearing
sb-&gt;s_fs_info field after calling fuse_conn_put().

[1] https://syzkaller.appspot.com/bug?id=a07a680ed0a9290585ca424546860464dd9658db

Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Reported-by: syzbot &lt;syzbot+ec3986119086fe4eec97@syzkaller.appspotmail.com&gt;
Fixes: 3b463ae0c626 ("fuse: invalidation reverse calls")
Cc: John Muir &lt;john@jmuir.com&gt;
Cc: Csaba Henk &lt;csaba@gluster.com&gt;
Cc: Anand Avati &lt;avati@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v2.6.31
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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