Skip to content
  1. Jun 30, 2021
  2. Jun 16, 2021
    • Greg Kroah-Hartman's avatar
      Linux 4.19.195 · eb575cd5
      Greg Kroah-Hartman authored
      
      
      Link: https://lore.kernel.org/r/20210614102643.797691914@linuxfoundation.org
      Tested-by: default avatarPavel Machek (CIP) <pavel@denx.de>
      Tested-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Tested-by: default avatarShuah Khan <skhan@linuxfoundation.org>
      Tested-by: default avatarJason Self <jason@bluehome.net>
      Tested-by: default avatarHulk Robot <hulkrobot@huawei.com>
      Tested-by: default avatarLinux Kernel Functional Testing <lkft@linaro.org>
      Tested-by: default avatarSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      v4.19.195
      eb575cd5
    • Linus Torvalds's avatar
      proc: only require mm_struct for writing · 2bc534ca
      Linus Torvalds authored
      commit 94f0b2d4 upstream.
      
      Commit 591a22c1 ("proc: Track /proc/$pid/attr/ opener mm_struct") we
      started using __mem_open() to track the mm_struct at open-time, so that
      we could then check it for writes.
      
      But that also ended up making the permission checks at open time much
      stricter - and not just for writes, but for reads too.  And that in turn
      caused a regression for at least Fedora 29, where NIC interfaces fail to
      start when using NetworkManager.
      
      Since only the write side wanted the mm_struct test, ignore any failures
      by __mem_open() at open time, leaving reads unaffected.  The write()
      time verification of the mm_struct pointer will then catch the failure
      case because a NULL pointer will not match a valid 'current->mm'.
      
      Link: https://lore.kernel.org/netdev/YMjTlp2FSJYvoyFa@unreal/
      Fixes: 591a22c1
      
       ("proc: Track /proc/$pid/attr/ opener mm_struct")
      Reported-and-tested-by: default avatarLeon Romanovsky <leon@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Christian Brauner <christian.brauner@ubuntu.com>
      Cc: Andrea Righi <andrea.righi@canonical.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2bc534ca
    • Liangyan's avatar
      tracing: Correct the length check which causes memory corruption · 31ceae38
      Liangyan authored
      commit 3e08a9f9 upstream.
      
      We've suffered from severe kernel crashes due to memory corruption on
      our production environment, like,
      
      Call Trace:
      [1640542.554277] general protection fault: 0000 [#1] SMP PTI
      [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G
      [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190
      [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286
      [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:
      0000000006e931bf
      [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:
      ffff9a45ff004300
      [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:
      0000000000000000
      [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
      ffffffff9a20608d
      [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:
      696c662f65636976
      [1640542.563128] FS:  00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)
      knlGS:0000000000000000
      [1640542.563937] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:
      00000000003606e0
      [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
      0000000000000400
      [1640542.566742] Call Trace:
      [1640542.567009]  anon_vma_clone+0x5d/0x170
      [1640542.567417]  __split_vma+0x91/0x1a0
      [1640542.567777]  do_munmap+0x2c6/0x320
      [1640542.568128]  vm_munmap+0x54/0x70
      [1640542.569990]  __x64_sys_munmap+0x22/0x30
      [1640542.572005]  do_syscall_64+0x5b/0x1b0
      [1640542.573724]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [1640542.575642] RIP: 0033:0x7f45d6e61e27
      
      James Wang has reproduced it stably on the latest 4.19 LTS.
      After some debugging, we finally proved that it's due to ftrace
      buffer out-of-bound access using a debug tool as follows:
      [   86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
      [   86.780806]  no_context+0xdf/0x3c0
      [   86.784327]  __do_page_fault+0x252/0x470
      [   86.788367]  do_page_fault+0x32/0x140
      [   86.792145]  page_fault+0x1e/0x30
      [   86.795576]  strncpy_from_unsafe+0x66/0xb0
      [   86.799789]  fetch_memory_string+0x25/0x40
      [   86.804002]  fetch_deref_string+0x51/0x60
      [   86.808134]  kprobe_trace_func+0x32d/0x3a0
      [   86.812347]  kprobe_dispatcher+0x45/0x50
      [   86.816385]  kprobe_ftrace_handler+0x90/0xf0
      [   86.820779]  ftrace_ops_assist_func+0xa1/0x140
      [   86.825340]  0xffffffffc00750bf
      [   86.828603]  do_sys_open+0x5/0x1f0
      [   86.832124]  do_syscall_64+0x5b/0x1b0
      [   86.835900]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      commit b220c049 ("tracing: Check length before giving out
      the filter buffer") adds length check to protect trace data
      overflow introduced in 0fc1b09f, seems that this fix can't prevent
      overflow entirely, the length check should also take the sizeof
      entry->array[0] into account, since this array[0] is filled the
      length of trace data and occupy addtional space and risk overflow.
      
      Link: https://lkml.kernel.org/r/20210607125734.1770447-1-liangyan.peng@linux.alibaba.com
      
      Cc: stable@vger.kernel.org
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Xunlei Pang <xlpang@linux.alibaba.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Fixes: b220c049
      
       ("tracing: Check length before giving out the filter buffer")
      Reviewed-by: default avatarXunlei Pang <xlpang@linux.alibaba.com>
      Reviewed-by: default avataryinbinbin <yinbinbin@alibabacloud.com>
      Reviewed-by: default avatarWetp Zhang <wetp.zy@linux.alibaba.com>
      Tested-by: default avatarJames Wang <jnwang@linux.alibaba.com>
      Signed-off-by: default avatarLiangyan <liangyan.peng@linux.alibaba.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31ceae38
    • Steven Rostedt (VMware)'s avatar
      ftrace: Do not blindly read the ip address in ftrace_bug() · 862dcc14
      Steven Rostedt (VMware) authored
      commit 6c14133d upstream.
      
      It was reported that a bug on arm64 caused a bad ip address to be used for
      updating into a nop in ftrace_init(), but the error path (rightfully)
      returned -EINVAL and not -EFAULT, as the bug caused more than one error to
      occur. But because -EINVAL was returned, the ftrace_bug() tried to report
      what was at the location of the ip address, and read it directly. This
      caused the machine to panic, as the ip was not pointing to a valid memory
      address.
      
      Instead, read the ip address with copy_from_kernel_nofault() to safely
      access the memory, and if it faults, report that the address faulted,
      otherwise report what was in that location.
      
      Link: https://lore.kernel.org/lkml/20210607032329.28671-1-mark-pk.tsai@mediatek.com/
      
      Cc: stable@vger.kernel.org
      Fixes: 05736a42
      
       ("ftrace: warn on failure to disable mcount callers")
      Reported-by: default avatarMark-PK Tsai <mark-pk.tsai@mediatek.com>
      Tested-by: default avatarMark-PK Tsai <mark-pk.tsai@mediatek.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      862dcc14
    • Ming Lei's avatar
      scsi: core: Only put parent device if host state differs from SHOST_CREATED · 681e5c84
      Ming Lei authored
      commit 1e0d4e62
      
       upstream.
      
      get_device(shost->shost_gendev.parent) is called after host state has
      switched to SHOST_RUNNING. scsi_host_dev_release() shouldn't release the
      parent device if host state is still SHOST_CREATED.
      
      Link: https://lore.kernel.org/r/20210602133029.2864069-5-ming.lei@redhat.com
      Cc: Bart Van Assche <bvanassche@acm.org>
      Cc: John Garry <john.garry@huawei.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Tested-by: default avatarJohn Garry <john.garry@huawei.com>
      Reviewed-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      681e5c84