Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 3月, 2020 2 次提交
    • Y
      pagecache: support percpu refcount to imporve performance · 8b9ea901
      由 Yunfeng Ye 提交于 
      euleros inclusion
category: feature
feature: pagecache percpu refcount
bugzilla: 31398
CVE: NA

-------------------------------------------------

The pagecache manages the file physical pages, and the life cycle of
page is managed by atomic counting. With the increasing number of cpu
cores, the cost of atomic counting is very large when reading file
pagecaches at large concurrent.

For example, when running nginx http application, the biggest hotspot is
found in the atomic operation of find_get_entry():

 11.94% [kernel] [k] find_get_entry
  7.45% [kernel] [k] do_tcp_sendpages
  6.12% [kernel] [k] generic_file_buffered_read

So we using the percpu refcount mechanism to fix this problem. and the
test result show that the read performance of nginx http can be improved
by 100%：

  worker   original(requests/sec)   percpu(requests/sec)   imporve
  64       759656.87                1627088.95             114.2%

Notes: we use page->lru to save percpu information, so the pages with
percpu attribute will not be recycled by memory recycling process, we
should avoid grow the file size unlimited.
Signed-off-by: NYunfeng Ye <yeyunfeng@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      8b9ea901
    • Y
      arm64: mm: support setting page attributes for debugging · 57457a65
      由 Yunfeng Ye 提交于 
      euleros inclusion
category: feature
feature: Memory debug feature

-------------------------------------------------

When pagealloc debug is enabled, block mappings or contiguous hints are
no longer used for linear address area. Therefore, support setting page
attributes in this case is useful for debugging memory corruption
problems.
Signed-off-by: NYunfeng Ye <yeyunfeng@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      57457a65
  3. 16 3月, 2020 6 次提交
    • S
      staging: android: ashmem: Disallow ashmem memory from being remapped · 07189052
      由 Suren Baghdasaryan 提交于 
      commit 6d67b029 upstream.

When ashmem file is mmapped, the resulting vma->vm_file points to the
backing shmem file with the generic fops that do not check ashmem
permissions like fops of ashmem do. If an mremap is done on the ashmem
region, then the permission checks will be skipped. Fix that by disallowing
mapping operation on the backing shmem file.
Reported-by: NJann Horn <jannh@google.com>
Signed-off-by: NSuren Baghdasaryan <surenb@google.com>
Cc: stable <stable@vger.kernel.org> # 4.4,4.9,4.14,4.18,5.4
Signed-off-by: NTodd Kjos <tkjos@google.com>
Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
Link: https://lore.kernel.org/r/20200127235616.48920-1-tkjos@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      07189052
    • D
      mm/resource: Return real error codes from walk failures · 24394177
      由 Dave Hansen 提交于 
      mainline inclusion
from mainline-v5.1-rc1
commit 5cd401ac
category: bugfix
bugzilla: 17339
CVE: NA

-------------------------------------------------

walk_system_ram_range() can return an error code either becuase
*it* failed, or because the 'func' that it calls returned an
error.  The memory hotplug does the following:

	ret = walk_system_ram_range(..., func);
        if (ret)
		return ret;

and 'ret' makes it out to userspace, eventually.  The problem
s, walk_system_ram_range() failues that result from *it* failing
(as opposed to 'func') return -1.  That leads to a very odd
-EPERM (-1) return code out to userspace.

Make walk_system_ram_range() return -EINVAL for internal
failures to keep userspace less confused.

This return code is compatible with all the callers that I
audited.
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ross Zwisler <zwisler@kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: linux-nvdimm@lists.01.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: Huang Ying <ying.huang@intel.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Keith Busch <keith.busch@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      24394177
    • J
      vt: selection, push sel_lock up · 88121b44
      由 Jiri Slaby 提交于 
      commit e8c75a30 upstream.

sel_lock cannot nest in the console lock. Thanks to syzkaller, the
kernel states firmly:

> WARNING: possible circular locking dependency detected
> 5.6.0-rc3-syzkaller #0 Not tainted
> ------------------------------------------------------
> syz-executor.4/20336 is trying to acquire lock:
> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>
> but task is already holding lock:
> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (sel_lock){+.+.}:
>        mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
>        set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
>        set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
>        tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
>        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364

This is ioctl(TIOCL_SETSEL).
Locks held on the path: console_lock -> sel_lock

> -> #1 (console_lock){+.+.}:
>        console_lock+0x46/0x70 kernel/printk/printk.c:2289
>        con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
>        n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
>        do_tty_write drivers/tty/tty_io.c:962 [inline]
>        tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046

This is write().
Locks held on the path: termios_rwsem -> console_lock

> -> #0 (&tty->termios_rwsem){++++}:
>        down_write+0x57/0x140 kernel/locking/rwsem.c:1534
>        tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>        mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
>        tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
>        paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
>        tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
>        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364

This is ioctl(TIOCL_PASTESEL).
Locks held on the path: sel_lock -> termios_rwsem

> other info that might help us debug this:
>
> Chain exists of:
>   &tty->termios_rwsem --> console_lock --> sel_lock

Clearly. From the above, we have:
 console_lock -> sel_lock
 sel_lock -> termios_rwsem
 termios_rwsem -> console_lock

Fix this by reversing the console_lock -> sel_lock dependency in
ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
Fixes: 07e6124a ("vt: selection, close sel_buffer race")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      88121b44
    • J
      vt: selection, push console lock down · 5f44c4ac
      由 Jiri Slaby 提交于 
      commit 4b70dd57 upstream.

We need to nest the console lock in sel_lock, so we have to push it down
a bit. Fortunately, the callers of set_selection_* just lock the console
lock around the function call. So moving it down is easy.

In the next patch, we switch the order.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Fixes: 07e6124a ("vt: selection, close sel_buffer race")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200228115406.5735-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      5f44c4ac
    • S
      net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup · d93d588d
      由 Sabrina Dubroca 提交于 
      mainline inclusion
from mainline-v5.5-rc1
commit 6c8991f4
category: bugfix
bugzilla: 13690
CVE: CVE-2020-1749

-------------------------------------------------

ipv6_stub uses the ip6_dst_lookup function to allow other modules to
perform IPv6 lookups. However, this function skips the XFRM layer
entirely.

All users of ipv6_stub->ip6_dst_lookup use ip_route_output_flow (via the
ip_route_output_key and ip_route_output helpers) for their IPv4 lookups,
which calls xfrm_lookup_route(). This patch fixes this inconsistent
behavior by switching the stub to ip6_dst_lookup_flow, which also calls
xfrm_lookup_route().

This requires some changes in all the callers, as these two functions
take different arguments and have different return types.

Fixes: 5f81bd2e ("ipv6: export a stub for IPv6 symbols used by vxlan")
Reported-by: NXiumei Mu <xmu@redhat.com>
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Conflicts:
  include/net/addrconf.h
  drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
  net/core/lwt_bpf.c
  net/tipc/udp_media.c
  net/ipv6/addrconf_core.c
  net/ipv6/af_inet6.c
  drivers/infiniband/core/addr.c
[yyl: adjust context]
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWenan Mao <maowenan@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      d93d588d
    • S
      net: ipv6: add net argument to ip6_dst_lookup_flow · e6a9ef86
      由 Sabrina Dubroca 提交于 
      mainline inclusion
from mainline-v5.5-rc1
commit c4e85f73
category: bugfix
bugzilla: 13690
CVE: CVE-2020-1749

It's prepare for fixing CVE-2020-1749.

-------------------------------------------------

This will be used in the conversion of ipv6_stub to ip6_dst_lookup_flow,
as some modules currently pass a net argument without a socket to
ip6_dst_lookup. This is equivalent to commit 343d60aa ("ipv6: change
ipv6_stub_impl.ipv6_dst_lookup to take net argument").
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NWenan Mao <maowenan@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      e6a9ef86
  5. 14 3月, 2020 6 次提交
  7. 12 3月, 2020 9 次提交
  9. 11 3月, 2020 4 次提交
  11. 05 3月, 2020 13 次提交
    • C
      livepatch/x86: enable livepatch config openeuler · 4b90845b
      由 Cheng Jian 提交于 
      hulk inclusion
category: feature
bugzilla: 5507
CVE: NA

---------------------------

We have completed the livepatch without ftrace for x86_64,
we can now enable it.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      4b90845b
    • C
      livepatch/x86: enable livepatch config for hulk · 6a07930a
      由 Cheng Jian 提交于 
      hulk inclusion
category: feature
bugzilla: 5507
CVE: NA

---------------------------

We have completed the livepatch without ftrace for x86_64,
we can now enable it.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      6a07930a
    • C
      livepatch/arm64: check active func in consistency stack checking · b6f7ad60
      由 Cheng Jian 提交于 
      hulk inclusion
category: bugfix
bugzilla: 5507/31358
CVE: NA
---------------------------

When doing consistency stack checking, if we try to patch a
function which has been patched already. We should check the
new function(not the origin func) that is activeness currently,
it's always the first entry in list func_node->func_stack.

Example :
	module : origin			livepatch v1		livepatch v2
	func   : old func A -[enable]=> new func A' -[enable]=> new func A''
	check  :		A			A'

when we try to patch function A to new function A'' by livepatch
v2, but the func A has already patched to function A' by livepatch
v1, so function A' which provided in livepatch v1 is active in the
stack instead of origin function A. Even if the long jump method is
used, we jump to the new function A' using a call without LR, the
origin function A will not appear in the stack. We must check the
active function A' in consistency stack checking.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      b6f7ad60
    • C
      livepatch/x86: check active func in consistency stack checking · 27057710
      由 Cheng Jian 提交于 
      hulk inclusion
category: bugfix
bugzilla: 5507/31358
CVE: NA
---------------------------

When doing consistency stack checking, if we try to patch a
function which has been patched already. We should check the
new function(not the origin func) that is activeness currently,
it's always the first entry in list func_node->func_stack.

Example :
	module : origin			livepatch v1		livepatch v2
	func   : old func A -[enable]=> new func A' -[enable]=> new func A''
	check  :		A			A'

when we try to patch function A to new function A'' by livepatch
v2, but the func A has already patched to function A' by livepatch
v1, so function A' which provided in livepatch v1 is active in the
stack instead of origin function A. Even if the long jump method is
used, we jump to the new function A' using a call without LR, the
origin function A will not appear in the stack. We must check the
active function A' in consistency stack checking.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      27057710
    • C
      livepatch/x86: support livepatch without ftrace · 7e2ab91e
      由 Cheng Jian 提交于 
      hulk inclusion
category: feature
bugzilla: 5507
CVE: NA

----------------------------------------

support livepatch without ftrace for x86_64

supported now:
        livepatch relocation when init_patch after load_module;
        instruction patched when enable;
	activeness function check;
	enforcing the patch stacking principle;

x86_64 use variable length instruction, so there's no need to consider
extra implementation for long jumps.
Signed-off-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NLi Bin <huawei.libin@huawei.com>
Tested-by: NYang ZuoTing <yangzuoting@huawei.com>
Tested-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      7e2ab91e
    • O
      KVM: nVMX: Check IO instruction VM-exit conditions · eb232fcd
      由 Oliver Upton 提交于 
      commit 35a571346a94fb93b5b3b6a599675ef3384bc75c upstream.

Consult the 'unconditional IO exiting' and 'use IO bitmaps' VM-execution
controls when checking instruction interception. If the 'use IO bitmaps'
VM-execution control is 1, check the instruction access against the IO
bitmaps to determine if the instruction causes a VM-exit.
Signed-off-by: NOliver Upton <oupton@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      eb232fcd
    • O
      KVM: nVMX: Refactor IO bitmap checks into helper function · 6959f6e4
      由 Oliver Upton 提交于 
      commit e71237d3ff1abf9f3388337cfebf53b96df2020d upstream.

Checks against the IO bitmap are useful for both instruction emulation
and VM-exit reflection. Refactor the IO bitmap checks into a helper
function.
Signed-off-by: NOliver Upton <oupton@google.com>
Reviewed-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      6959f6e4
    • P
      KVM: nVMX: Don't emulate instructions in guest mode · eb561a7a
      由 Paolo Bonzini 提交于 
      commit 07721feee46b4b248402133228235318199b05ec upstream.

vmx_check_intercept is not yet fully implemented. To avoid emulating
instructions disallowed by the L1 hypervisor, refuse to emulate
instructions by default.

Cc: stable@vger.kernel.org
[Made commit, added commit msg - Oliver]
Signed-off-by: NOliver Upton <oupton@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      eb561a7a
    • L
      floppy: check FDC index for errors before assigning it · 2ad1a109
      由 Linus Torvalds 提交于 
      commit 2e90ca68b0d2f5548804f22f0dd61145516171e3 upstream.

Jordy Zomer reported a KASAN out-of-bounds read in the floppy driver in
wait_til_ready().

Which on the face of it can't happen, since as Willy Tarreau points out,
the function does no particular memory access.  Except through the FDCS
macro, which just indexes a static allocation through teh current fdc,
which is always checked against N_FDC.

Except the checking happens after we've already assigned the value.

The floppy driver is a disgrace (a lot of it going back to my original
horrd "design"), and has no real maintainer.  Nobody has the hardware,
and nobody really cares.  But it still gets used in virtual environment
because it's one of those things that everybody supports.

The whole thing should be re-written, or at least parts of it should be
seriously cleaned up.  The 'current fdc' index, which is used by the
FDCS macro, and which is often shadowed by a local 'fdc' variable, is a
prime example of how not to write code.

But because nobody has the hardware or the motivation, let's just fix up
the immediate problem with a nasty band-aid: test the fdc index before
actually assigning it to the static 'fdc' variable.
Reported-by: NJordy Zomer <jordy@simplyhacker.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      2ad1a109
    • S
      ext4: add cond_resched() to __ext4_find_entry() · ef91f0f3
      由 Shijie Luo via Kernel 提交于 
      mainline inclusion
from mainline-v5.6-rc3
commit 9424ef56e13a1f14c57ea161eed3ecfdc7b2770e
category: bugfix
bugzilla: 31127
CVE: NA

-------------------------------------------------
We tested a soft lockup problem in linux 4.19 which could also
be found in linux 5.x.

When dir inode takes up a large number of blocks, and if the
directory is growing when we are searching, it's possible the
restart branch could be called many times, and the do while loop
could hold cpu a long time.

Here is the call trace in linux 4.19.

[  473.756186] Call trace:
[  473.756196]  dump_backtrace+0x0/0x198
[  473.756199]  show_stack+0x24/0x30
[  473.756205]  dump_stack+0xa4/0xcc
[  473.756210]  watchdog_timer_fn+0x300/0x3e8
[  473.756215]  __hrtimer_run_queues+0x114/0x358
[  473.756217]  hrtimer_interrupt+0x104/0x2d8
[  473.756222]  arch_timer_handler_virt+0x38/0x58
[  473.756226]  handle_percpu_devid_irq+0x90/0x248
[  473.756231]  generic_handle_irq+0x34/0x50
[  473.756234]  __handle_domain_irq+0x68/0xc0
[  473.756236]  gic_handle_irq+0x6c/0x150
[  473.756238]  el1_irq+0xb8/0x140
[  473.756286]  ext4_es_lookup_extent+0xdc/0x258 [ext4]
[  473.756310]  ext4_map_blocks+0x64/0x5c0 [ext4]
[  473.756333]  ext4_getblk+0x6c/0x1d0 [ext4]
[  473.756356]  ext4_bread_batch+0x7c/0x1f8 [ext4]
[  473.756379]  ext4_find_entry+0x124/0x3f8 [ext4]
[  473.756402]  ext4_lookup+0x8c/0x258 [ext4]
[  473.756407]  __lookup_hash+0x8c/0xe8
[  473.756411]  filename_create+0xa0/0x170
[  473.756413]  do_mkdirat+0x6c/0x140
[  473.756415]  __arm64_sys_mkdirat+0x28/0x38
[  473.756419]  el0_svc_common+0x78/0x130
[  473.756421]  el0_svc_handler+0x38/0x78
[  473.756423]  el0_svc+0x8/0xc
[  485.755156] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [tmp:5149]

Add cond_resched() to avoid soft lockup and to provide a better
system responding.

Link: https://lore.kernel.org/r/20200215080206.13293-1-luoshijie1@huawei.comSigned-off-by: NShijie Luo <luoshijie1@huawei.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Reviewed-by: NJan Kara <jack@suse.cz>
Cc: stable@kernel.org
Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ef91f0f3
    • X
      x86 / config: add openeuler_defconfig · 95a54772
      由 Xiongfeng Wang 提交于 
      hulk inclusion
category: config
bugzilla: 31089
CVE: NA

-----------------------------

Add openeuler_defconfig for openeuler itself.
Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      95a54772
    • Z
      files_cgroup: Fix soft lockup when refcnt overflow. · 22f98d8e
      由 Zhang Xiaoxu 提交于 
      hulk inclusion
category: bugfix
bugzilla: 31087
CVE: NA

---------------------

There is a soft lockup call trace as below:
  CPU: 0 PID: 1360 Comm: imapsvcd Kdump: loaded Tainted: G           OE
  task: ffff8a7296e1eeb0 ti: ffff8a7296aa0000 task.ti: ffff8a7296aa0000
  RIP: 0010:[<ffffffffb691ecb4>]  [<ffffffffb691ecb4>]
  __css_tryget+0x24/0x50
  RSP: 0018:ffff8a7296aa3db8  EFLAGS: 00000a87
  RAX: 0000000080000000 RBX: ffff8a7296aa3df8 RCX: ffff8a72820d9a08
  RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8a72820d9a00
  RBP: ffff8a7296aa3db8 R08: 000000000001c360 R09: ffffffffb6a478f4
  R10: ffffffffb6935e83 R11: ffffffffffffffd0 R12: 0000000057d35cd8
  R13: 000000d000000002 R14: ffffffffb6892fbe R15: 000000d000000002
  FS:  0000000000000000(0000) GS:ffff8a72fec00000(0063)
  knlGS:00000000c6e65b40
  CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
  CR2: 0000000057d35cd8 CR3: 00000007e8008000 CR4: 00000000003607f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   [<ffffffffb6a93578>] files_cgroup_assign+0x48/0x60
   [<ffffffffb6a47972>] dup_fd+0xb2/0x2f0
   [<ffffffffb6935e83>] ? audit_alloc+0xe3/0x180
   [<ffffffffb6893a03>] copy_process+0xbd3/0x1a40
   [<ffffffffb6894a21>] do_fork+0x91/0x320
   [<ffffffffb6f329e6>] ? trace_do_page_fault+0x56/0x150
   [<ffffffffb6894d36>] SyS_clone+0x16/0x20
   [<ffffffffb6f3bf8c>] ia32_ptregs_common+0x4c/0xfc
   code: 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8d 4f 08 48 89 e5 8b
         47 08 8d 90 00 00 00 80 85 c0 0f 49 d0 8d 72 01 89 d0 f0 0f b1

When the child process exit, we doesn't call dec refcnt, so, the refcnt
maybe overflow. Then the 'task_get_css' will dead loop because the
'css_refcnt' will return an unbias refcnt, if the refcnt is negitave,
'__css_tryget' always return false, then 'task_get_css' dead looped.

The child process always call 'close_files' when exit, add dec refcnt in
it.
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      22f98d8e
    • J
      vt: selection, close sel_buffer race · 099d032f
      由 Jiri Slaby 提交于 
      mainline inclusion
from mainline-v5.6-rc2
commit 07e6124a
category: bugfix
bugzilla: 13690
CVE: CVE-2020-8648

-------------------------------------------------

syzkaller reported this UAF:
BUG: KASAN: use-after-free in n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
Read of size 1 at addr ffff8880089e40e9 by task syz-executor.1/13184

CPU: 0 PID: 13184 Comm: syz-executor.1 Not tainted 5.4.7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:
...
 kasan_report+0xe/0x20 mm/kasan/common.c:634
 n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
 tty_ldisc_receive_buf+0xac/0x190 drivers/tty/tty_buffer.c:461
 paste_selection+0x297/0x400 drivers/tty/vt/selection.c:372
 tioclinux+0x20d/0x4e0 drivers/tty/vt/vt.c:3044
 vt_ioctl+0x1bcf/0x28d0 drivers/tty/vt/vt_ioctl.c:364
 tty_ioctl+0x525/0x15a0 drivers/tty/tty_io.c:2657
 vfs_ioctl fs/ioctl.c:47 [inline]

It is due to a race between parallel paste_selection (TIOCL_PASTESEL)
and set_selection_user (TIOCL_SETSEL) invocations. One uses sel_buffer,
while the other frees it and reallocates a new one for another
selection. Add a mutex to close this race.

The mutex takes care properly of sel_buffer and sel_buffer_lth only. The
other selection global variables (like sel_start, sel_end, and sel_cons)
are protected only in set_selection_user. The other functions need quite
some more work to close the races of the variables there. This is going
to happen later.

This likely fixes (I am unsure as there is no reproducer provided) bug
206361 too. It was marked as CVE-2020-8648.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reported-by: syzbot+59997e8d5cbdc486e6f6@syzkaller.appspotmail.com
References: https://bugzilla.kernel.org/show_bug.cgi?id=206361
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200210081131.23572-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      099d032f