Skip to content

L
linux
Switch branch/tag
  1. 26 Mar, 2021 2 commits
  3. 23 Mar, 2021 1 commit
    • Chao Yu's avatar
      f2fs: fix to align to section for fallocate() on pinned file · e1175f02
      Chao Yu authored 
      Now, fallocate() on a pinned file only allocates blocks which aligns
to segment rather than section, so GC may try to migrate pinned file's
block, and after several times of failure, pinned file's block could
be migrated to other place, however user won't be aware of such
condition, and then old obsolete block address may be readed/written
incorrectly.

To avoid such condition, let's try to allocate pinned file's blocks
with section alignment.
Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      e1175f02
  5. 12 Mar, 2021 32 commits
  7. 11 Mar, 2021 5 commits
    • Linus Torvalds's avatar
      Merge tag 'media/v5.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 28806e4d
      Linus Torvalds authored 
      Pull media fixes from Mauro Carvalho Chehab:
 "A couple of fixes:

   - fix a build issue with CEC

   - fix a deadlock at usbtv driver

   - fix some null pointer address issues at vsp1 driver

   - fix a wrong bitmap setting at rkisp1 driver"

* tag 'media/v5.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  media: rkisp1: params: fix wrong bits settings
  media: v4l: vsp1: Fix uif null pointer access
  media: v4l: vsp1: Fix bru null pointer access
  media: usbtv: Fix deadlock on suspend
  media: rc: compile rc-cec.c into rc-core
      28806e4d
    • Axel Lin's avatar
      regulator: mt6315: Fix off-by-one for .n_voltages · d450293c
      Axel Lin authored 
      The valid selector is 0 ~ 0xbf, so the .n_voltages should be 0xc0.
Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210311020558.579597-1-axel.lin@ingics.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      d450293c
    • Ard Biesheuvel's avatar
      arm64: mm: remove unused __cpu_uses_extended_idmap[_level()] · 30b26757
      Ard Biesheuvel authored 
      These routines lost all existing users during the latest merge window so
we can remove them. This avoids the need to fix them in the context of
fixing a regression related to the ID map on 52-bit VA kernels.
Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20210310171515.416643-3-ardb@kernel.orgSigned-off-by: default avatarWill Deacon <will@kernel.org>
      30b26757
    • Ard Biesheuvel's avatar
      arm64: mm: use a 48-bit ID map when possible on 52-bit VA builds · 7ba8f2b2
      Ard Biesheuvel authored 
      52-bit VA kernels can run on hardware that is only 48-bit capable, but
configure the ID map as 52-bit by default. This was not a problem until
recently, because the special T0SZ value for a 52-bit VA space was never
programmed into the TCR register anwyay, and because a 52-bit ID map
happens to use the same number of translation levels as a 48-bit one.

This behavior was changed by commit 1401bef7 ("arm64: mm: Always update
TCR_EL1 from __cpu_set_tcr_t0sz()"), which causes the unsupported T0SZ
value for a 52-bit VA to be programmed into TCR_EL1. While some hardware
simply ignores this, Mark reports that Amberwing systems choke on this,
resulting in a broken boot. But even before that commit, the unsupported
idmap_t0sz value was exposed to KVM and used to program TCR_EL2 incorrectly
as well.

Given that we already have to deal with address spaces being either 48-bit
or 52-bit in size, the cleanest approach seems to be to simply default to
a 48-bit VA ID map, and only switch to a 52-bit one if the placement of the
kernel in DRAM requires it. This is guaranteed not to happen unless the
system is actually 52-bit VA capable.

Fixes: 90ec95cd ("arm64: mm: Introduce VA_BITS_MIN")
Reported-by: default avatarMark Salter <msalter@redhat.com>
Link: http://lore.kernel.org/r/20210310003216.410037-1-msalter@redhat.comSigned-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20210310171515.416643-2-ardb@kernel.orgSigned-off-by: default avatarWill Deacon <will@kernel.org>
      7ba8f2b2
    • Daiyue Zhang's avatar
      configfs: fix a use-after-free in __configfs_open_file · 14fbbc82
      Daiyue Zhang authored 
      Commit b0841eef ("configfs: provide exclusion between IO and removals")
uses ->frag_dead to mark the fragment state, thus no bothering with extra
refcount on config_item when opening a file. The configfs_get_config_item
was removed in __configfs_open_file, but not with config_item_put. So the
refcount on config_item will lost its balance, causing use-after-free
issues in some occasions like this:

Test:
1. Mount configfs on /config with read-only items:
drwxrwx--- 289 root   root            0 2021-04-01 11:55 /config
drwxr-xr-x   2 root   root            0 2021-04-01 11:54 /config/a
--w--w--w-   1 root   root         4096 2021-04-01 11:53 /config/a/1.txt
......

2. Then run:
for file in /config
do
echo $file
grep -R 'key' $file
done

3. __configfs_open_file will be called in parallel, the first one
got called will do:
if (file->f_mode & FMODE_READ) {
	if (!(inode->i_mode & S_IRUGO))
		goto out_put_module;
			config_item_put(buffer->item);
				kref_put()
					package_details_release()
						kfree()

the other one will run into use-after-free issues like this:
BUG: KASAN: use-after-free in __configfs_open_file+0x1bc/0x3b0
Read of size 8 at addr fffffff155f02480 by task grep/13096
CPU: 0 PID: 13096 Comm: grep VIP: 00 Tainted: G        W       4.14.116-kasan #1
TGID: 13096 Comm: grep
Call trace:
dump_stack+0x118/0x160
kasan_report+0x22c/0x294
__asan_load8+0x80/0x88
__configfs_open_file+0x1bc/0x3b0
configfs_open_file+0x28/0x34
do_dentry_open+0x2cc/0x5c0
vfs_open+0x80/0xe0
path_openat+0xd8c/0x2988
do_filp_open+0x1c4/0x2fc
do_sys_open+0x23c/0x404
SyS_openat+0x38/0x48

Allocated by task 2138:
kasan_kmalloc+0xe0/0x1ac
kmem_cache_alloc_trace+0x334/0x394
packages_make_item+0x4c/0x180
configfs_mkdir+0x358/0x740
vfs_mkdir2+0x1bc/0x2e8
SyS_mkdirat+0x154/0x23c
el0_svc_naked+0x34/0x38

Freed by task 13096:
kasan_slab_free+0xb8/0x194
kfree+0x13c/0x910
package_details_release+0x524/0x56c
kref_put+0xc4/0x104
config_item_put+0x24/0x34
__configfs_open_file+0x35c/0x3b0
configfs_open_file+0x28/0x34
do_dentry_open+0x2cc/0x5c0
vfs_open+0x80/0xe0
path_openat+0xd8c/0x2988
do_filp_open+0x1c4/0x2fc
do_sys_open+0x23c/0x404
SyS_openat+0x38/0x48
el0_svc_naked+0x34/0x38

To fix this issue, remove the config_item_put in
__configfs_open_file to balance the refcount of config_item.

Fixes: b0841eef ("configfs: provide exclusion between IO and removals")
Signed-off-by: default avatarDaiyue Zhang <zhangdaiyue1@huawei.com>
Signed-off-by: default avatarYi Chen <chenyi77@huawei.com>
Signed-off-by: default avatarGe Qiu <qiuge@huawei.com>
Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      14fbbc82
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7