Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 5月, 2020 8 次提交
    • Q
      mwifiex: Fix possible buffer overflows in mwifiex_cmd_append_vsie_tlv() · 9d41031e
      由 Qing Xu 提交于 
      [ Upstream commit b70261a288ea4d2f4ac7cd04be08a9f0f2de4f4d ]

mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking
the destination size may trigger a buffer overflower,
which a local user could use to cause denial of service
or the execution of arbitrary code.
Fix it by putting the length check before calling memcpy().
Signed-off-by: NQing Xu <m1s5p6688@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      9d41031e
    • Q
      mwifiex: Fix possible buffer overflows in mwifiex_ret_wmm_get_status() · 1aa1d812
      由 Qing Xu 提交于 
      [ Upstream commit 3a9b153c5591548612c3955c9600a98150c81875 ]

mwifiex_ret_wmm_get_status() calls memcpy() without checking the
destination size.Since the source is given from remote AP which
contains illegal wmm elements , this may trigger a heap buffer
overflow.
Fix it by putting the length check before calling memcpy().
Signed-off-by: NQing Xu <m1s5p6688@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      1aa1d812
    • D
      scsi: mptfusion: Fix double fetch bug in ioctl · f4ac7202
      由 Dan Carpenter 提交于 
      commit 28d76df18f0ad5bcf5fa48510b225f0ed262a99b upstream.

Tom Hatskevich reported that we look up "iocp" then, in the called
functions we do a second copy_from_user() and look it up again.
The problem that could cause is:

drivers/message/fusion/mptctl.c
   674          /* All of these commands require an interrupt or
   675           * are unknown/illegal.
   676           */
   677          if ((ret = mptctl_syscall_down(iocp, nonblock)) != 0)
                                               ^^^^
We take this lock.

   678                  return ret;
   679
   680          if (cmd == MPTFWDOWNLOAD)
   681                  ret = mptctl_fw_download(arg);
                                                 ^^^
Then the user memory changes and we look up "iocp" again but a different
one so now we are holding the incorrect lock and have a race condition.

   682          else if (cmd == MPTCOMMAND)
   683                  ret = mptctl_mpt_command(arg);

The security impact of this bug is not as bad as it could have been
because these operations are all privileged and root already has
enormous destructive power.  But it's still worth fixing.

This patch passes the "iocp" pointer to the functions to avoid the
second lookup.  That deletes 100 lines of code from the driver so
it's a nice clean up as well.

Link: https://lore.kernel.org/r/20200114123414.GA7957@kadamReported-by: NTom Hatskevich <tom2001tom.23@gmail.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      f4ac7202
    • F
      mt76: fix array overflow on receiving too many fragments for a packet · e24fc936
      由 Felix Fietkau 提交于 
      commit b102f0c522cf668c8382c56a4f771b37d011cda2 upstream.

If the hardware receives an oversized packet with too many rx fragments,
skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
This becomes especially visible if it corrupts the freelist pointer of
a slab page.

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      e24fc936
    • Y
      net: hns3: change the order of reinitializing RoCE and VF during reset · 2fe54aae
      由 Yufeng Mo 提交于 
      driver inclusion
category: bugfix
bugzilla: NA
CVE: NA

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

The HNS RDMA driver will support VF device later, whose
re-initialization should be done after PF's. This patch
changes the order of hclge_reset_prepare_up() and
hclge_notify_roce_client(), so that PF's roce client
will be reinitialized before VF's
Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
Reviewed-by: NWeiwei Deng <dengweiwei@huawei.com>
Reviewed-by: NPeng Li <lipeng321@huawei.com>
Reviewed-by: NShengzui You <youshengzui@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      2fe54aae
    • S
      net: hns3: update hns3 version to 1.9.37.9 · ea3bb9b2
      由 Shengzui You 提交于 
      driver inclusion
category: other
bugzilla: NA
CVE: NA

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

This patch is used to modify the hns3 driver version to 1.9.37.9
Signed-off-by: NShengzui You <youshengzui@huawei.com>
Reviewed-by: NWeiwei Deng <dengweiwei@huawei.com>
Reviewed-by: NZhaohui Zhong <zhongzhaohui@huawei.com>
Reviewed-by: NJunxin Chen <chenjunxin1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ea3bb9b2
    • Y
      Revert "scsi: fix failing unload of a LLDD module" · 6056c041
      由 Ye Bin 提交于 
      hulk inclusion
category: bugfix
bugzilla: 34271
CVE: NA

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

This reverts commit fd72360bc94ad304136beb56e8ff2ec089113bb8.

test setp:
...
rmmod hisi_sas_v3_hw
lsmod
fdisk -l
insomd hisi_sas_v3_hw.ko
lsmod
fdisk -l
....

We get follow error when we test by above test steps.

[ 3660.259153] [ffff00000116f000] pgd=00002027ffffe003, pud=00002027ffffd003,
pmd=00002027cdf28003, pte=0000000000000000
[ 3660.269719] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[ 3660.275266] Modules linked in: hisi_sas_v3_hw(+) hisi_sas_main hns_roce_hw_v2(O)
hns_roce(O) rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi
ib_ipoib ib_umad realtek hns3(O) hclge(O) hnae3(O) crc32_ce crct10dif_ce hisi_hpre
hisi_zip hisi_qm uacce hisi_trng_v2 rng_core sfc lbc ip_tables x_tables libsas
scsi_transport_sas [last unloaded: hisi_sas_main]
[ 3660.308227] Process smartd (pid: 19570, stack limit = 0x000000001103634d)
[ 3660.314985] CPU: 31 PID: 19570 Comm: smartd Kdump: loaded Tainted: G O 4.19.36-g32894fc #1
[ 3660.324504] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD,
BIOS 2280-V2 CS V3.B220.02 03/27/2020
[ 3660.334110] pstate: 60400009 (nZCv daif +PAN -UAO)
[ 3660.338882] pc : scsi_device_put+0x18/0x38
[ 3660.342961] lr : scsi_disk_put+0x3c/0x58
[ 3660.346865] sp : ffff0000158a3cb0
[ 3660.350164] x29: ffff0000158a3cb0 x28: ffff8027b8111000
[ 3660.355451] x27: 00000000080a005d x26: 0000000000000000
[ 3660.360738] x25: ffff8027c6310398 x24: ffff8027cd2ec410
[ 3660.366025] x23: ffff000009811000 x22: ffff80276d274750
[ 3660.371312] x21: ffff8027abdd5000 x20: ffff8027b8110800
[ 3660.376599] x19: ffff8027abdd5000 x18: 0000000000000000
[ 3660.381886] x17: 0000000000000000 x16: 0000000000000000
[ 3660.387172] x15: 0000000000000000 x14: 0000000000000000
[ 3660.392459] x13: ffff000009996cd0 x12: ffffffffffffffff
[ 3660.397746] x11: ffff000009996cc8 x10: 0000000000000000
[ 3660.403033] x9 : 0000000000000000 x8 : 0000000040000000
[ 3660.408320] x7 : ffff0000098116c8 x6 : 0000000000000000
[ 3660.413607] x5 : ffff00000820ebbc x4 : ffff7e009eb8fb20
[ 3660.418894] x3 : 0000000080400009 x2 : ffff8027ae3ec600
[ 3660.424180] x1 : 71b6030ca20bb300 x0 : ffff00000116f000
[ 3660.429467] Call trace:
[ 3660.431904]  scsi_device_put+0x18/0x38
[ 3660.435636]  scsi_disk_put+0x3c/0x58
[ 3660.439195]  sd_release+0x50/0xc0
[ 3660.442496]  __blkdev_put+0x20c/0x220
[ 3660.446141]  blkdev_put+0x4c/0x110
[ 3660.449527]  blkdev_close+0x1c/0x28
[ 3660.453000]  __fput+0x88/0x1b8
[ 3660.456042]  ____fput+0xc/0x18
[ 3660.459085]  task_work_run+0x94/0xb0
[ 3660.462646]  do_notify_resume+0x17c/0x180
[ 3660.466637]  work_pending+0x8/0x10
[ 3660.470022] Code: f9000bf3 aa0003f3 f9400000 f9404c00 (f9400000)
[ 3660.476089] ---[ end trace ca1d0144f9241f71 ]---

void scsi_device_put(struct scsi_device *sdev)
{
        module_put(sdev->host->hostt->module); ---> error code
        put_device(&sdev->sdev_gendev);
}

  When access "sdev->host->hostt" occurs exception, as "sdev->host->hostt" is point
to the module address space which is already removed. module_delete first check
module reference count, then call module exit function. So after pass
module reference count check and before call module exit, we can call
scsi_device_get function successfully.
  As "scsi: fix failing unload of a LLDD module" lead to call scsi_device_get
success during remove module. We revert this patch, "scsi: fixup kernel warning
during rmmod()" already fixed previous error.
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      6056c041
    • C
      s390/mm: fix page table upgrade vs 2ndary address mode accesses · e589cb8b
      由 Christian Borntraeger 提交于 
      mainline inclusion
from mainline-v5.7-rc4
commit 316ec154810960052d4586b634156c54d0778f74
category: bugfix
bugzilla: 13690
CVE: CVE-2020-11884

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

A page table upgrade in a kernel section that uses secondary address
mode will mess up the kernel instructions as follows:

Consider the following scenario: two threads are sharing memory.
On CPU1 thread 1 does e.g. strnlen_user().  That gets to
        old_fs = enable_sacf_uaccess();
        len = strnlen_user_srst(src, size);
and
                "   la    %2,0(%1)\n"
                "   la    %3,0(%0,%1)\n"
                "   slgr  %0,%0\n"
                "   sacf  256\n"
                "0: srst  %3,%2\n"
in strnlen_user_srst().  At that point we are in secondary space mode,
control register 1 points to kernel page table and instruction fetching
happens via c1, rather than usual c13.  Interrupts are not disabled, for
obvious reasons.

On CPU2 thread 2 does MAP_FIXED mmap(), forcing the upgrade of page table
from 3-level to e.g. 4-level one.  We'd allocated new top-level table,
set it up and now we hit this:
                notify = 1;
                spin_unlock_bh(&mm->page_table_lock);
        }
        if (notify)
                on_each_cpu(__crst_table_upgrade, mm, 0);
OK, we need to actually change over to use of new page table and we
need that to happen in all threads that are currently running.  Which
happens to include the thread 1.  IPI is delivered and we have
static void __crst_table_upgrade(void *arg)
{
        struct mm_struct *mm = arg;

        if (current->active_mm == mm)
                set_user_asce(mm);
        __tlb_flush_local();
}
run on CPU1.  That does
static inline void set_user_asce(struct mm_struct *mm)
{
        S390_lowcore.user_asce = mm->context.asce;
OK, user page table address updated...
        __ctl_load(S390_lowcore.user_asce, 1, 1);
... and control register 1 set to it.
        clear_cpu_flag(CIF_ASCE_PRIMARY);
}

IPI is run in home space mode, so it's fine - insns are fetched
using c13, which always points to kernel page table.  But as soon
as we return from the interrupt, previous PSW is restored, putting
CPU1 back into secondary space mode, at which point we no longer
get the kernel instructions from the kernel mapping.

The fix is to only fixup the control registers that are currently in use
for user processes during the page table update.  We must also disable
interrupts in enable_sacf_uaccess to synchronize the cr and
thread.mm_segment updates against the on_each-cpu.

Fixes: 0aaba41b ("s390: remove all code using the access register mode")
Cc: stable@vger.kernel.org # 4.15+
Reported-by: NAl Viro <viro@zeniv.linux.org.uk>
Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
References: CVE-2020-11884
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      e589cb8b
  3. 09 5月, 2020 2 次提交
  5. 06 5月, 2020 4 次提交
  7. 28 4月, 2020 25 次提交
  9. 26 4月, 2020 1 次提交