<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/fs/udf, branch linux-4.17.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.17.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-4.17.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/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.rulkc.org/pub/scm/linux/kernel/git/stable/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>Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2018-05-21T18:54:57+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-05-21T18:54:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5997aab0a11ea27ee8e520ecc551ed18fd3e8296'/>
<id>urn:sha1:5997aab0a11ea27ee8e520ecc551ed18fd3e8296</id>
<content type='text'>
Pull vfs fixes from Al Viro:
 "Assorted fixes all over the place"

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  aio: fix io_destroy(2) vs. lookup_ioctx() race
  ext2: fix a block leak
  nfsd: vfs_mkdir() might succeed leaving dentry negative unhashed
  cachefiles: vfs_mkdir() might succeed leaving dentry negative unhashed
  unfuck sysfs_mount()
  kernfs: deal with kernfs_fill_super() failures
  cramfs: Fix IS_ENABLED typo
  befs_lookup(): use d_splice_alias()
  affs_lookup: switch to d_splice_alias()
  affs_lookup(): close a race with affs_remove_link()
  fix breakage caused by d_find_alias() semantics change
  fs: don't scan the inode cache before SB_BORN is set
  do d_instantiate/unlock_new_inode combinations safely
  iov_iter: fix memory leak in pipe_get_pages_alloc()
  iov_iter: fix return type of __pipe_get_pages()
</content>
</entry>
<entry>
<title>do d_instantiate/unlock_new_inode combinations safely</title>
<updated>2018-05-11T19:36:37+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2018-05-04T12:23: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=1e2e547a93a00ebc21582c06ca3c6cfea2a309ee'/>
<id>urn:sha1:1e2e547a93a00ebc21582c06ca3c6cfea2a309ee</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>udf: Fix leak of UTF-16 surrogates into encoded strings</title>
<updated>2018-04-18T14:34:55+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2018-04-12T15:22: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=44f06ba8297c7e9dfd0e49b40cbe119113cca094'/>
<id>urn:sha1:44f06ba8297c7e9dfd0e49b40cbe119113cca094</id>
<content type='text'>
OSTA UDF specification does not mention whether the CS0 charset in case
of two bytes per character encoding should be treated in UTF-16 or
UCS-2. The sample code in the standard does not treat UTF-16 surrogates
in any special way but on systems such as Windows which work in UTF-16
internally, filenames would be treated as being in UTF-16 effectively.
In Linux it is more difficult to handle characters outside of Base
Multilingual plane (beyond 0xffff) as NLS framework works with 2-byte
characters only. Just make sure we don't leak UTF-16 surrogates into the
resulting string when loading names from the filesystem for now.

CC: stable@vger.kernel.org # &gt;= v4.6
Reported-by: Mingye Wang &lt;arthur200126@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: fix potential refcnt problem of nls module</title>
<updated>2018-03-02T13:23:12+00:00</updated>
<author>
<name>Chengguang Xu</name>
<email>cgxu519@icloud.com</email>
</author>
<published>2018-02-25T13:25: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=785dffe1daf95c176504dea3069c9df11af7ff15'/>
<id>urn:sha1:785dffe1daf95c176504dea3069c9df11af7ff15</id>
<content type='text'>
When specifiying iocharset multiple times in a mount or once/multiple in
a remount, current option parsing may cause inaccurate refcount of nls
module.  Also, in the failure cleanup of option parsing, the condition
of calling unload_nls is not sufficient.

Signed-off-by: Chengguang Xu &lt;cgxu519@icloud.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Do not mark possibly inconsistent filesystems as closed</title>
<updated>2018-03-02T13:22:57+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2018-02-27T17:55:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b72e632c6c7e29343651b0e26539b2e01444dfe6'/>
<id>urn:sha1:b72e632c6c7e29343651b0e26539b2e01444dfe6</id>
<content type='text'>
If logical volume integrity descriptor contains non-closed integrity
type when mounting the volume, there are high chances that the volume is
not consistent (device was detached before the filesystem was
unmounted). Don't touch integrity type of such volume so that fsck can
recognize it and check such filesystem.

Reported-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Remove never implemented mount options</title>
<updated>2018-02-27T09:25:33+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2018-02-22T13:33:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f0c4a81711cb773b60cb8f90173e6491e67bf74f'/>
<id>urn:sha1:f0c4a81711cb773b60cb8f90173e6491e67bf74f</id>
<content type='text'>
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Provide saner default for invalid uid / gid</title>
<updated>2018-02-27T09:25:33+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2018-02-22T09:39:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=116e5258e4115aca0c64ac0bf40ded3b353ed626'/>
<id>urn:sha1:116e5258e4115aca0c64ac0bf40ded3b353ed626</id>
<content type='text'>
Currently when UDF filesystem is recorded without uid / gid (ids are set
to -1), we will assign INVALID_[UG]ID to vfs inode unless user uses uid=
and gid= mount options. In such case filesystem could not be modified in
any way as VFS refuses to modify files with invalid ids (even by root).
This is confusing to users and not very useful default since such media
mode is generally used for removable media. Use overflow[ug]id instead
so that at least root can modify the filesystem.

Reported-by: Steve Kenton &lt;skenton@ou.edu&gt;
Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Clean up handling of invalid uid/gid</title>
<updated>2018-02-27T09:25:33+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2018-02-22T09:28:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c9850f4d4c5d645125869fe0fa206fb662bd98b'/>
<id>urn:sha1:0c9850f4d4c5d645125869fe0fa206fb662bd98b</id>
<content type='text'>
Current code relies on the fact that invalid uid/gid as defined by UDF
2.60 3.3.3.1 and 3.3.3.2 coincides with invalid uid/gid as used by the
user namespaces implementation. Since this is only lucky coincidence,
clean this up to avoid future surprises in case user namespaces
implementation changes. Also this is more robust in presence of valid
(from UDF point of view) uids / gids which do not map into current user
namespace.

Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
<entry>
<title>udf: Apply uid/gid mount options also to new inodes &amp; chown</title>
<updated>2018-02-27T09:25:33+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2018-02-21T16:59:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ecd10aa42819cd5dcf639d25575e95a5bda8d08a'/>
<id>urn:sha1:ecd10aa42819cd5dcf639d25575e95a5bda8d08a</id>
<content type='text'>
Currently newly created files belong to current user despite
uid=&lt;number&gt; / gid=&lt;number&gt; mount options. This is confusing to users
(as owner of the file will change after remount / eviction from cache)
and also inconsistent with e.g. FAT with the same mount option. So apply
uid=&lt;number&gt; and gid=&lt;number&gt; also to newly created inodes and similarly
as FAT disallow to change owner of the file in this case.

Reported-by: Steve Kenton &lt;skenton@ou.edu&gt;
Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
</entry>
</feed>
