<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/reiserfs, 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>2018-11-27T15:05:36Z</updated>
<entry>
<title>reiserfs: propagate errors from fill_with_dentries() properly</title>
<updated>2018-11-27T15:05:36Z</updated>
<author>
<name>Jann Horn</name>
</author>
<published>2018-10-30T22:06:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bb55901e291f3c879d7edd71aae83048229f2acd'/>
<id>urn:sha1:bb55901e291f3c879d7edd71aae83048229f2acd</id>
<content type='text'>
[ Upstream commit b10298d56c9623f9b173f19959732d3184b35f4f ]

fill_with_dentries() failed to propagate errors up to
reiserfs_for_each_xattr() properly.  Plumb them through.

Note that reiserfs_for_each_xattr() is only used by
reiserfs_delete_xattrs() and reiserfs_chown_xattrs().  The result of
reiserfs_delete_xattrs() is discarded anyway, the only difference there is
whether a warning is printed to dmesg.  The result of
reiserfs_chown_xattrs() does matter because it can block chowning of the
file to which the xattrs belong; but either way, the resulting state can
have misaligned ownership, so my patch doesn't improve things greatly.

Credit for making me look at this code goes to Al Viro, who pointed out
that the -&gt;actor calling convention is suboptimal and should be changed.

Link: http://lkml.kernel.org/r/20180802163335.83312-1-jannh@google.com
Signed-off-by: Jann Horn &lt;jannh@google.com&gt;
Reviewed-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Eric Biggers &lt;ebiggers@google.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&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;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>reiserfs: change j_timestamp type to time64_t</title>
<updated>2018-09-26T06:33:50Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2018-08-22T04:59:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c0aa3622ac3578163722733c018cb59267465c38'/>
<id>urn:sha1:c0aa3622ac3578163722733c018cb59267465c38</id>
<content type='text'>
[ Upstream commit 8b73ce6a4bae4fe12bcb2c361c0da4183c2e1b6f ]

This uses the deprecated time_t type but is write-only, and could be
removed, but as Jeff explains, having a timestamp can be usefule for
post-mortem analysis in crash dumps.

In order to remove one of the last instances of time_t, this changes the
type to time64_t, same as j_trans_start_time.

Link: http://lkml.kernel.org/r/20180622133315.221210-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: Jeff Mahoney &lt;jeffm@suse.com&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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>reiserfs: fix broken xattr handling (heap corruption, bad retval)</title>
<updated>2018-08-28T05:21:37Z</updated>
<author>
<name>Jann Horn</name>
</author>
<published>2018-08-22T04:59:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=88f8dcdb69e35da54b5b7579403d365df457f093'/>
<id>urn:sha1:88f8dcdb69e35da54b5b7579403d365df457f093</id>
<content type='text'>
commit a13f085d111e90469faf2d9965eb39b11c114d7e upstream.

This fixes the following issues:

- When a buffer size is supplied to reiserfs_listxattr() such that each
  individual name fits, but the concatenation of all names doesn't fit,
  reiserfs_listxattr() overflows the supplied buffer.  This leads to a
  kernel heap overflow (verified using KASAN) followed by an out-of-bounds
  usercopy and is therefore a security bug.

- When a buffer size is supplied to reiserfs_listxattr() such that a
  name doesn't fit, -ERANGE should be returned.  But reiserfs instead just
  truncates the list of names; I have verified that if the only xattr on a
  file has a longer name than the supplied buffer length, listxattr()
  incorrectly returns zero.

With my patch applied, -ERANGE is returned in both cases and the memory
corruption doesn't happen anymore.

Credit for making me clean this code up a bit goes to Al Viro, who pointed
out that the -&gt;actor calling convention is suboptimal and should be
changed.

Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Signed-off-by: Jann Horn &lt;jannh@google.com&gt;
Acked-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Eric Biggers &lt;ebiggers@google.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>do d_instantiate/unlock_new_inode combinations safely</title>
<updated>2018-05-30T05:47:29Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2018-05-04T12:23:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b90b64116b1136c9c965e019283daf6100a6d1ac'/>
<id>urn:sha1:b90b64116b1136c9c965e019283daf6100a6d1ac</id>
<content type='text'>
commit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.

For anything NFS-exported we do _not_ want to unlock new inode
before it has grown an alias; original set of fixes got the
ordering right, but missed the nasty complication in case of
lockdep being enabled - unlock_new_inode() does
	lockdep_annotate_inode_mutex_key(inode)
which can only be done before anyone gets a chance to touch
-&gt;i_mutex.  Unfortunately, flipping the order and doing
unlock_new_inode() before d_instantiate() opens a window when
mkdir can race with open-by-fhandle on a guessed fhandle, leading
to multiple aliases for a directory inode and all the breakage
that follows from that.

	Correct solution: a new primitive (d_instantiate_new())
combining these two in the right order - lockdep annotate, then
d_instantiate(), then the rest of unlock_new_inode().  All
combinations of d_instantiate() with unlock_new_inode() should
be converted to that.

Cc: stable@kernel.org	# 2.6.29 and later
Tested-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Reviewed-by: Andreas Dilger &lt;adilger@dilger.ca&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fs/reiserfs/journal.c: add missing resierfs_warning() arg</title>
<updated>2018-04-24T07:29:25Z</updated>
<author>
<name>Andrew Morton</name>
</author>
<published>2018-04-10T23:34:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8b85ff3d8074943482dd54f295cda4f1e31077c1'/>
<id>urn:sha1:8b85ff3d8074943482dd54f295cda4f1e31077c1</id>
<content type='text'>
commit 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 upstream.

One use of the reiserfs_warning() macro in journal_init_dev() is missing
a parameter, causing the following warning:

  REISERFS warning (device loop0): journal_init_dev: Cannot open '%s': %i journal_init_dev:

This also causes a WARN_ONCE() warning in the vsprintf code, and then a
panic if panic_on_warn is set.

  Please remove unsupported %/ in format string
  WARNING: CPU: 1 PID: 4480 at lib/vsprintf.c:2138 format_decode+0x77f/0x830 lib/vsprintf.c:2138
  Kernel panic - not syncing: panic_on_warn set ...

Just add another string argument to the macro invocation.

Addresses https://syzkaller.appspot.com/bug?id=0627d4551fdc39bf1ef5d82cd9eef587047f7718

Link: http://lkml.kernel.org/r/d678ebe1-6f54-8090-df4c-b9affad62293@infradead.org
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reported-by: &lt;syzbot+6bd77b88c1977c03f584@syzkaller.appspotmail.com&gt;
Tested-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Acked-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Jan Kara &lt;jack@suse.com&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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>reiserfs: Make cancel_old_flush() reliable</title>
<updated>2018-03-22T08:37:14Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2017-04-05T12:09:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b74fb8c983a0cf8e9e0d9937e4d4e6b964d7c241'/>
<id>urn:sha1:b74fb8c983a0cf8e9e0d9937e4d4e6b964d7c241</id>
<content type='text'>
[ Upstream commit 71b0576bdb862e964a82c73327cdd1a249c53e67 ]

Currently canceling of delayed work that flushes old data using
cancel_old_flush() does not prevent work from being requeued. Thus
in theory new work can be queued after cancel_old_flush() from
reiserfs_freeze() has run. This will become larger problem once
flush_old_commits() can requeue the work itself.

Fix the problem by recording in sbi-&gt;work_queue that flushing work is
canceled and should not be requeued.

Signed-off-by: Jan Kara &lt;jack@suse.cz&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>reiserfs: don't preallocate blocks for extended attributes</title>
<updated>2018-01-31T13:46:14Z</updated>
<author>
<name>Jeff Mahoney</name>
</author>
<published>2017-06-22T20:35:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1f31381a6cc0e0e5fb06371268388c00f8d04df4'/>
<id>urn:sha1:1f31381a6cc0e0e5fb06371268388c00f8d04df4</id>
<content type='text'>
commit 54930dfeb46e978b447af0fb8ab4e181c1bf9d7a upstream.

Most extended attributes will fit in a single block.  More importantly,
we drop the reference to the inode while holding the transaction open
so the preallocated blocks aren't released.  As a result, the inode
may be evicted before it's removed from the transaction's prealloc list
which can cause memory corruption.

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.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>reiserfs: fix race in prealloc discard</title>
<updated>2018-01-31T13:46:14Z</updated>
<author>
<name>Jeff Mahoney</name>
</author>
<published>2017-06-22T20:47:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9ff49848ab5f2402478dd384d19966a82b9b1f09'/>
<id>urn:sha1:9ff49848ab5f2402478dd384d19966a82b9b1f09</id>
<content type='text'>
commit 08db141b5313ac2f64b844fb5725b8d81744b417 upstream.

The main loop in __discard_prealloc is protected by the reiserfs write lock
which is dropped across schedules like the BKL it replaced.  The problem is
that it checks the value, calls a routine that schedules, and then adjusts
the state.  As a result, two threads that are calling
reiserfs_prealloc_discard at the same time can race when one calls
reiserfs_free_prealloc_block, the lock is dropped, and the other calls
reiserfs_free_prealloc_block with the same block number.  In the right
circumstances, it can cause the prealloc count to go negative.

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.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>posix_acl: Clear SGID bit when setting file permissions</title>
<updated>2017-05-08T05:44:10Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2016-09-19T15:39:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d8333c045f045385a914013a220cd1ed54c88d48'/>
<id>urn:sha1:d8333c045f045385a914013a220cd1ed54c88d48</id>
<content type='text'>
commit 073931017b49d9458aa351605b43a7e34598caef upstream.

When file permissions are modified via chmod(2) and the user is not in
the owning group or capable of CAP_FSETID, the setgid bit is cleared in
inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
permissions as well as the new ACL, but doesn't clear the setgid bit in
a similar way; this allows to bypass the check in chmod(2).  Fix that.

References: CVE-2016-7097
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Amit Pundir &lt;amit.pundir@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>reiserfs: destroy allocated commit workqueue</title>
<updated>2015-01-16T14:59:53Z</updated>
<author>
<name>Jiri Slaby</name>
</author>
<published>2014-12-12T15:29:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=66a2cbe36f007405338bfacee540717f8ee35b1d'/>
<id>urn:sha1:66a2cbe36f007405338bfacee540717f8ee35b1d</id>
<content type='text'>
commit fa0c5540739320258c3e3a45aaae9dae467b2504 upstream.

When resirefs is trying to mount a partition, it creates a commit
workqueue (sbi-&gt;commit_wq). But when mount fails later, the workqueue
is not freed.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Reported-by: auxsvr@gmail.com
Reported-by: Benoît Monin &lt;benoit.monin@gmx.fr&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: reiserfs-devel@vger.kernel.org
Fixes: 797d9016ceca69879bb273218810fa0beef46aac
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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