<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/fs, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-05-23T01:36:37Z</updated>
<entry>
<title>ext4: set h_journal if there is a failure starting a reserved handle</title>
<updated>2018-05-23T01:36:37Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2018-04-18T15:49:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cfc992934dea5d019a24edb2a79274727aa0de48'/>
<id>urn:sha1:cfc992934dea5d019a24edb2a79274727aa0de48</id>
<content type='text'>
[ Upstream commit b2569260d55228b617bd82aba6d0db2faeeb4116 ]

If ext4 tries to start a reserved handle via
jbd2_journal_start_reserved(), and the journal has been aborted, this
can result in a NULL pointer dereference.  This is because the fields
h_journal and h_transaction in the handle structure share the same
memory, via a union, so jbd2_journal_start_reserved() will clear
h_journal before calling start_this_handle().  If this function fails
due to an aborted handle, h_journal will still be NULL, and the call
to jbd2_journal_free_reserved() will pass a NULL journal to
sub_reserve_credits().

This can be reproduced by running "kvm-xfstests -c dioread_nolock
generic/475".

Cc: stable@kernel.org # 3.11
Fixes: 8f7d89f36829b ("jbd2: transaction reservation support")
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Andreas Dilger &lt;adilger@dilger.ca&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>jbd2: fix use after free in kjournald2()</title>
<updated>2018-05-23T01:36:36Z</updated>
<author>
<name>Sahitya Tummala</name>
<email>stummala@codeaurora.org</email>
</author>
<published>2017-02-02T01:49:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0759c1c2f140ec56a9fec96dddf9e5beb89f3b48'/>
<id>urn:sha1:0759c1c2f140ec56a9fec96dddf9e5beb89f3b48</id>
<content type='text'>
[ Upstream commit dbfcef6b0f4012c57bc0b6e0e660d5ed12a5eaed ]

Below is the synchronization issue between unmount and kjournald2
contexts, which results into use after free issue in kjournald2().
Fix this issue by using journal-&gt;j_state_lock to synchronize the
wait_event() done in journal_kill_thread() and the wake_up() done
in kjournald2().

TASK 1:
umount cmd:
   |--jbd2_journal_destroy() {
       |--journal_kill_thread() {
            write_lock(&amp;journal-&gt;j_state_lock);
	    journal-&gt;j_flags |= JBD2_UNMOUNT;
	    ...
	    write_unlock(&amp;journal-&gt;j_state_lock);
	    wake_up(&amp;journal-&gt;j_wait_commit);	   TASK 2 wakes up here:
	    					   kjournald2() {
						     ...
						     checks JBD2_UNMOUNT flag and calls goto end-loop;
						     ...
						     end_loop:
						       write_unlock(&amp;journal-&gt;j_state_lock);
						       journal-&gt;j_task = NULL; --&gt; If this thread gets
						       pre-empted here, then TASK 1 wait_event will
						       exit even before this thread is completely
						       done.
	    wait_event(journal-&gt;j_wait_done_commit, journal-&gt;j_task == NULL);
	    ...
	    write_lock(&amp;journal-&gt;j_state_lock);
	    write_unlock(&amp;journal-&gt;j_state_lock);
	  }
       |--kfree(journal);
     }
}
						       wake_up(&amp;journal-&gt;j_wait_done_commit); --&gt; this step
						       now results into use after free issue.
						   }

Signed-off-by: Sahitya Tummala &lt;stummala@codeaurora.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: do not allow creating sockets except with SMB1 posix exensions</title>
<updated>2018-05-23T01:36:35Z</updated>
<author>
<name>Steve French</name>
<email>smfrench@gmail.com</email>
</author>
<published>2018-04-20T17:19:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=91c3835434860b674ef45bcbfa4a0ea61e2d9194'/>
<id>urn:sha1:91c3835434860b674ef45bcbfa4a0ea61e2d9194</id>
<content type='text'>
[ Upstream commit 1d0cffa674cfa7d185a302c8c6850fc50b893bed ]

RHBZ: 1453123

Since at least the 3.10 kernel and likely a lot earlier we have
not been able to create unix domain sockets in a cifs share
when mounted using the SFU mount option (except when mounted
with the cifs unix extensions to Samba e.g.)
Trying to create a socket, for example using the af_unix command from
xfstests will cause :
BUG: unable to handle kernel NULL pointer dereference at 00000000
00000040

Since no one uses or depends on being able to create unix domains sockets
on a cifs share the easiest fix to stop this vulnerability is to simply
not allow creation of any other special files than char or block devices
when sfu is used.

Added update to Ronnie's patch to handle a tcon link leak, and
to address a buf leak noticed by Gustavo and Colin.

Acked-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
CC:  Colin Ian King &lt;colin.king@canonical.com&gt;
Reviewed-by: Pavel Shilovsky &lt;pshilov@microsoft.com&gt;
Reported-by: Eryu Guan &lt;eguan@redhat.com&gt;
Signed-off-by: Ronnie Sahlberg &lt;lsahlber@redhat.com&gt;
Signed-off-by: Steve French &lt;smfrench@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>fanotify: fix logic of events on child</title>
<updated>2018-05-23T01:36:35Z</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2018-04-04T20:42:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6bc43ca0b94727516f5f42362308be8585120017'/>
<id>urn:sha1:6bc43ca0b94727516f5f42362308be8585120017</id>
<content type='text'>
[ Upstream commit 54a307ba8d3cd00a3902337ffaae28f436eeb1a4 ]

When event on child inodes are sent to the parent inode mark and
parent inode mark was not marked with FAN_EVENT_ON_CHILD, the event
will not be delivered to the listener process. However, if the same
process also has a mount mark, the event to the parent inode will be
delivered regadless of the mount mark mask.

This behavior is incorrect in the case where the mount mark mask does
not contain the specific event type. For example, the process adds
a mark on a directory with mask FAN_MODIFY (without FAN_EVENT_ON_CHILD)
and a mount mark with mask FAN_CLOSE_NOWRITE (without FAN_ONDIR).

A modify event on a file inside that directory (and inside that mount)
should not create a FAN_MODIFY event, because neither of the marks
requested to get that event on the file.

Fixes: 1968f5eed54c ("fanotify: use both marks when possible")
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ext4: bugfix for mmaped pages in mpage_release_unused_pages()</title>
<updated>2018-05-23T01:36:35Z</updated>
<author>
<name>wangguang</name>
<email>wang.guang55@zte.com.cn</email>
</author>
<published>2016-09-15T15:32:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=697acc5a549c082e2fa6f053a3d3dc9831d4f943'/>
<id>urn:sha1:697acc5a549c082e2fa6f053a3d3dc9831d4f943</id>
<content type='text'>
[ Upstream commit 4e800c0359d9a53e6bf0ab216954971b2515247f ]

Pages clear buffers after ext4 delayed block allocation failed,
However, it does not clean its pte_dirty flag.
if the pages unmap ,in cording to the pte_dirty ,
unmap_page_range may try to call __set_page_dirty,

which may lead to the bugon at
mpage_prepare_extent_to_map:head = page_buffers(page);.

This patch just call clear_page_dirty_for_io to clean pte_dirty
at mpage_release_unused_pages for pages mmaped.

Steps to reproduce the bug:

（1） mmap a file in ext4
	addr = (char *)mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED,
	       	            fd, 0);
	memset(addr, 'i', 4096);

（2） return EIO at

	ext4_writepages-&gt;mpage_map_and_submit_extent-&gt;mpage_map_one_extent

which causes this log message to be print:

                ext4_msg(sb, KERN_CRIT,
                        "Delayed block allocation failed for "
                        "inode %lu at logical offset %llu with"
                        " max blocks %u with error %d",
                        inode-&gt;i_ino,
                        (unsigned long long)map-&gt;m_lblk,
                        (unsigned)map-&gt;m_len, -err);

(3）Unmap the addr cause warning at

	__set_page_dirty:WARN_ON_ONCE(warn &amp;&amp; !PageUptodate(page));

(4) wait for a minute,then bugon happen.

Cc: stable@vger.kernel.org
Signed-off-by: wangguang &lt;wangguang03@zte.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>autofs: mount point create should honour passed in mode</title>
<updated>2018-05-23T01:36:35Z</updated>
<author>
<name>Ian Kent</name>
<email>raven@themaw.net</email>
</author>
<published>2018-04-20T21:55:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5f282f5e88c30efba5ed77dac8144cd3390ccfe5'/>
<id>urn:sha1:5f282f5e88c30efba5ed77dac8144cd3390ccfe5</id>
<content type='text'>
[ Upstream commit 1e6306652ba18723015d1b4967fe9de55f042499 ]

The autofs file system mkdir inode operation blindly sets the created
directory mode to S_IFDIR | 0555, ingoring the passed in mode, which can
cause selinux dac_override denials.

But the function also checks if the caller is the daemon (as no-one else
should be able to do anything here) so there's no point in not honouring
the passed in mode, allowing the daemon to set appropriate mode when
required.

Link: http://lkml.kernel.org/r/152361593601.8051.14014139124905996173.stgit@pluto.themaw.net
Signed-off-by: Ian Kent &lt;raven@themaw.net&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>Don't leak MNT_INTERNAL away from internal mounts</title>
<updated>2018-05-23T01:36:35Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2018-04-20T02:03:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=af89f8d755df58e351445d3cf6e50e57644bc9ae'/>
<id>urn:sha1:af89f8d755df58e351445d3cf6e50e57644bc9ae</id>
<content type='text'>
[ Upstream commit 16a34adb9392b2fe4195267475ab5b472e55292c ]

We want it only for the stuff created by SB_KERNMOUNT mounts, *not* for
their copies.  As it is, creating a deep stack of bindings of /proc/*/ns/*
somewhere in a new namespace and exiting yields a stack overflow.

Cc: stable@kernel.org
Reported-by: Alexander Aring &lt;aring@mojatatu.com&gt;
Bisected-by: Kirill Tkhai &lt;ktkhai@virtuozzo.com&gt;
Tested-by: Kirill Tkhai &lt;ktkhai@virtuozzo.com&gt;
Tested-by: Alexander Aring &lt;aring@mojatatu.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>jffs2_kill_sb(): deal with failed allocations</title>
<updated>2018-05-23T01:36:35Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2018-04-03T03:56:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=34d5b4283fb6b1843c25967363f739efb918ba4b'/>
<id>urn:sha1:34d5b4283fb6b1843c25967363f739efb918ba4b</id>
<content type='text'>
[ Upstream commit c66b23c2840446a82c389e4cb1a12eb2a71fa2e4 ]

jffs2_fill_super() might fail to allocate jffs2_sb_info;
jffs2_kill_sb() must survive that.

Cc: stable@kernel.org
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ext4: don't allow r/w mounts if metadata blocks overlap the superblock</title>
<updated>2018-05-23T01:36:34Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2018-03-30T02:10:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=176df3e2add7cd7029a3493ea825e5582cb84ef0'/>
<id>urn:sha1:176df3e2add7cd7029a3493ea825e5582cb84ef0</id>
<content type='text'>
[ Upstream commit 18db4b4e6fc31eda838dd1c1296d67dbcb3dc957 ]

If some metadata block, such as an allocation bitmap, overlaps the
superblock, it's very likely that if the file system is mounted
read/write, the results will not be pretty.  So disallow r/w mounts
for file systems corrupted in this particular way.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>jbd2: if the journal is aborted then don't allow update of the log tail</title>
<updated>2018-05-23T01:36:33Z</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2018-02-19T17:22:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=63df8d82efef1be1d8f6c55d8582e4aeaf7ab800'/>
<id>urn:sha1:63df8d82efef1be1d8f6c55d8582e4aeaf7ab800</id>
<content type='text'>
[ Upstream commit 85e0c4e89c1b864e763c4e3bb15d0b6d501ad5d9 ]

This updates the jbd2 superblock unnecessarily, and on an abort we
shouldn't truncate the log.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
</feed>
