- Mar 21, 2020
-
-
Xiongfeng Wang authoredhulk inclusion category: config bugzilla: 31390 CVE: NA Accessing sysfs-efivars interface '/sys/firmware/efi/vars' may have some problem. We can access the new efivarfs interface '/sys/firmware/efi/efivars' instead. So disable CONFIG_EFI_VARS and keep CONFIG_EFIVAR_FS enabled. Link: https://gitee.com/openeuler/kernel/issues/I1BN57 Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 20, 2020
-
-
Yang Yingliang authored
hulk inclusion category: bugfix bugzilla: 13690 CVE: CVE-2019-19039 ------------------------------------------------- Avoid print register messages when ret is -ENOTENT. Reviewed-by:
Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Ronnie Sahlberg authored
mainline inclusion from mainline-5.2-rc6 commit 0ff2b018 category: bugfix bugzilla: 16811 CVE: NA https://gitee.com/src-openeuler/cifs-utils/issues/I1C1QY?from=project-issue ------------------------------------------------- RH Bugzilla: 1702264 We need to protect so that the call to smb2_reconnect() in smb2_reconnect_server() does not end up freeing the session because it can lead to a use after free and crash. Reviewed-by:
Aurelien Aptel <aaptel@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
Conflicts:
fs/cifs/cifsproto.h
fs/cifs/connect.c
[yyl: make cifs_put_smb_ses() extern]
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 18, 2020
-
-
Zheng Bin authored
hulk inclusion category: bugfix bugzilla: 31088 CVE: NA --------------------------- If fdblocks < mp->m_alloc_set_aside, statp->f_bfree will overflow. When we df -h /mnt(xfs mount point), will show this: Filesystem Size Used Avail Use% Mounted on /dev/loop0 17M -64Z -32K 100% /mnt We can construct an img like this: dd if=/dev/zero of=xfs.img bs=1M count=20 mkfs.xfs -d agcount=1 xfs.img xfs_db -x xfs.img sb 0 write fdblocks 0 agf 0 write freeblks 0 write longest 0 quit Make sure statp->f_bfree does not underflow. Signed-off-by:
Zheng Bin <zhengbin13@huawei.com>
Reviewed-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Zheng Bin authored
hulk inclusion category: bugfix bugzilla: 31088 CVE: NA --------------------------- Use fuzz(hydra) to test XFS and automatically generate tmp.img(XFS v5 format, but some metadata is wrong) xfs_repair information(just one AG): agf_freeblks 0, counted 3224 in ag 0 agf_longest 0, counted 3224 in ag 0 sb_fdblocks 3228, counted 3224 Test as follows: mount tmp.img tmpdir cp file1M tmpdir sync In 4.19-stable, sync will stuck, while in linux-next, sync not stuck. The reason is same to commit d0c7feaf ("xfs: add agf freeblocks verify in xfs_agf_verify"), cause agf_longest is 0, we can not block this in xfs_agf_verify. Make sure fdblocks is always inited in mount(also init ifree, icount). xfs_mountfs xfs_check_summary_counts xfs_initialize_perag_data Signed-off-by:
Zheng Bin <zhengbin13@huawei.com>
Reviewed-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Christoph Hellwig authored
mainline inclusion from mainline-5.5-rc1 commit 50f6bb6b category: bugfix bugzilla: 31596 CVE: NA --------------------------- Just check for file-type enabled directories directly. Signed-off-by:
Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Conflicts:
fs/xfs/libxfs/xfs_dir2_priv.h
fs/xfs/libxfs/xfs_dir2_sf.c
fs/xfs/xfs_dir2_readdir.c
[zb: since patch 84915e1b, 707e0dda, e91ec882, 04df34ac
not merged, adjust code]
Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
Reviewed-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Yufen Yu authored
hulk inclusion category: bugfix bugzilla: 31388 CVE: NA --------------------------- After introducing commit 5b18b5a7 ("block: delete part_round_stats and switch to less precise counting"), '%util' accounted by iostat will be over reality data. In fact, the device is quite idle, but iostat may show '%util' as a big number (e.g. 50%). It can produce by fio: fio --name=1 --direct=1 --bs=4k --rw=read --filename=/dev/sda \ --thinktime=4ms --runtime=180 We fix this by reserving part_round_stats() in io start path. fixes: 5b18b5a7 ("block: delete part_round_stats and switch to less precise counting") Signed-off-by:
Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Mikulas Patocka authored
mainline inclusion from mainline-5.0-rc1 commit 5b18b5a7 category: bugfix bugzilla: 31388 CVE: NA --------------------------- We want to convert to per-cpu in_flight counters. The function part_round_stats needs the in_flight counter every jiffy, it would be too costly to sum all the percpu variables every jiffy, so it must be deleted. part_round_stats is used to calculate two counters - time_in_queue and io_ticks. time_in_queue can be calculated without part_round_stats, by adding the duration of the I/O when the I/O ends (the value is almost as exact as the previously calculated value, except that time for in-progress I/Os is not counted). io_ticks can be approximated by increasing the value when I/O is started or ended and the jiffies value has changed. If the I/Os take less than a jiffy, the value is as exact as the previously calculated value. If the I/Os take more than a jiffy, io_ticks can drift behind the previously calculated value. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Conflict:
block/bio.c
block/blk-core.c
block/blk-merge.c
block/genhd.c
include/linux/genhd.h
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Yilu Lin authored
hulk inclusion category: bugfix bugzilla: 31384 CVE: NA ------------------------------------------------- This patch is used to fix the bug in collect_uncached_read_data() that rc is automatically converted from a signed number to an unsigned number when the CIFS asynchronous read fails. It will cause ctx->rc is error. Example: Share a directory and create a file on the Windows OS. Mount the directory to the Linux OS using CIFS. On the CIFS client of the Linux OS, invoke the pread interface to deliver the read request. The size of the read length plus offset of the read request is greater than the maximum file size. In this case, the CIFS server on the Windows OS returns a failure message (for example, the return value of smb2.nt_status is STATUS_INVALID_PARAMETER). After receiving the response message, the CIFS client parses smb2.nt_status to STATUS_INVALID_PARAMETER and converts it to the Linux error code (rdata->result=-22). Then the CIFS client invokes the collect_uncached_read_data function to assign the value of rdata->result to rc, that is, rc=rdata->result=-22. The type of the ctx->total_len variable is unsigned integer, the type of the rc variable is integer, and the type of the ctx->rc variable is ssize_t. Therefore, during the ternary operation, the value of rc is automatically converted to an unsigned number. The final result is ctx->rc=4294967274. However, the expected result is ctx->rc=-22. https://patchwork.kernel.org/patch/11444477/ Signed-off-by:
Yilu Lin <linyilu@huawei.com>
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shaozhengchao authored
driver inclusion category:bugfix bugzilla:4472 CVE:NA ----------------------------------------------------------------------- Magic number rectification Signed-off-by:
Shaozhengchao <shaozhengchao@huawei.com>
Reviewed-by: Luoshaokai <luoshaokai@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shaozhengchao authored
net/hinic: slove the problem that VF may be disconnected when vm reboot and receive lots of broadcast packets. driver inclusion category:bugfix bugzilla:4472 CVE:NA ----------------------------------------------------------------------- slove the problem that VF may be disconnected when vm reboot and receive lots of broadcast packets. When vm is rebooting, VF receives lots of broadcast packects and VF may be disconnected. VF receives broadcast packect and VF driver will clear INTR_ON flag in setting msix process. Then VF driver will not enable interrupt if INTR_ON flag is set. As a result, VF will not process any hadware interrpt. In order to solve this problem, VF driver should be enable the interrpt first and then set msix state. Signed-off-by:
Shaozhengchao <shaozhengchao@huawei.com>
Reviewed-by: Luoshaokai <luoshaokai@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Xiongfeng Wang authored
hulk inclusion category: config bugzilla: 31390 CVE: NA Accessing sysfs-efivars interface '/sys/firmware/efi/vars' may have some problem. We can access the new efivarfs interface '/sys/firmware/efi/efivars' instead. So disable CONFIG_EFI_VARS and keep CONFIG_EFIVAR_FS enabled. Link: https://gitee.com/openeuler/kernel/issues/I1BN57 Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 17, 2020
-
-
Yunfeng Ye authored
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:
Yunfeng Ye <yeyunfeng@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Yunfeng Ye authored
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:
Yunfeng Ye <yeyunfeng@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 16, 2020
-
-
Suren Baghdasaryan authored
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:
Jann Horn <jannh@google.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: stable <stable@vger.kernel.org> # 4.4,4.9,4.14,4.18,5.4
Signed-off-by: Todd Kjos <tkjos@google.com>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Link: https://lore.kernel.org/r/20200127235616.48920-1-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Dave Hansen authored
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:
Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Bjorn 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: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Jiri Slaby authored
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:
Jiri 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.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Jiri Slaby authored
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:
Jiri 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.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Sabrina Dubroca authored
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:
Xiumei Mu <xmu@redhat.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David 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: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Wenan Mao <maowenan@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Sabrina Dubroca authored
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:
Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Wenan Mao <maowenan@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 14, 2020
-
-
Cheng Jian authored
hulk inclusion category: config bugzilla: 28204 CVE: NA The fcoe service failed to start because we did not enable CONFIG_FCOE just enable it. Link: https://gitee.com/open_euler/dashboard?issue_id=I1B9O9 Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Cheng Jian authored
hulk inclusion category: config bugzilla: 28204 CVE: NA Two config option confirmations are not needed. CONFIG_VIDEO_ADV_DEBUG CONFIG_INFINIBAND_IPOIB_DEBUG So removed them from openeuler config Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
shenhao authored
driver inclusion category: debug bugzilla: NA CVE: NA --------------------------------------------- This patch update the number of version Signed-off-by:
shenhao <shenhao21@huawei.com>
Reviewed-by: Zhong Zhaohui <zhongzhaohui@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
shenhao authored
driver inclusion category: debug bugzilla: NA CVE: NA ---------------------------------------------------- This patch adds dumping vlan filter config in debugfs to add more DFX method about vlan filter. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: shenhao <shenhao21@huawei.com>
Reviewed-by: Zhong Zhaohui <zhongzhaohui@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
shenhao authored
driver inclusion category: debug bugzilla: NA CVE: NA ---------------------------------------------------------- This patch increase vlan tag0 when close the port_base_vlan Signed-off-by:
liaoguojia <liaoguojia@huawei.com>
Signed-off-by: shenhao <shenhao21@huawei.com>
Reviewed-by: Zhong Zhaohui <zhongzhaohui@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
shenhao authored
driver inclusion category: Feature bugzilla: NA CVE: NA --------------------------------------------------- This patch adds support for extended VLAN mode, as we call dynamic vlan mode. In this mode, vf vlan filter will be switch between enable and disable, according to user configuration. This patch also adds support for QOS in vlan 802.1Q protocol. Signed-off-by:
liaoguojia <liaoguojia@huawei.com>
Signed-off-by: shenhao <shenhao21@huawei.com>
Reviewed-by: Zhong Zhaohui <zhongzhaohui@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 12, 2020
-
-
Shaozhengchao authored
driver inclusion category:bugfix bugzilla:4472 CVE:NA ----------------------------------------------------------------------- hinic driver code compliance rectification. 1.Process return value of snprintf and sscanf function. 2.Modify devil number. Signed-off-by:
Shaozhengchao <shaozhengchao@huawei.com>
Reviewed-by: Luoshaokai <luoshaokai@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shaozhengchao authored
driver inclusion category:bugfix bugzilla:31091 CVE:NA ----------------------------------------------------------------------- To solve the problem that the network card hangs when receiving the skb which frag_size=0 In order to solve this problem, hinic driver adds a judgment on the legality of frag_size in tx process. If size of lastest frags are all zero, hinic driver will ignore this frags. If size of some frags in the middle is zero, hinic driver will drop this skb. Signed-off-by:
Shaozhengchao <shaozhengchao@huawei.com>
Reviewed-by: Luoshaokai <luoshaokai@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shengzui You authored
driver inclusion category: feature bugzilla: NA CVE: NA -------------------------------- This patch adds support for reading the optical module eeprom info via "ethtool -m". Signed-off-by:
Shengzui You <youshengzui@huawei.com>
Reviewed-by: Weiwei Deng <dengweiwei@huawei.com>
Reviewed-by: Zhaohui Zhong <zhongzhaohui@huawei.com>
Reviewed-by: Junxing Chen <chenjunxin1@huawei.com>
Reviewed-by: Zhong Zhaohui <zhongzhaohui@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shengzui You authored
driver inclusion category: feature bugzilla: NA CVE: NA ------------------------- This patch is used to modify hns3 version to 1.9.37.1 Signed-off-by:
Shengzui You <youshengzui@huawei.com>
Reviewed-by: Weiwei Deng <dengweiwei@huawei.com>
Reviewed-by: Zhaohui Zhong <zhongzhaohui@huawei.com>
Reviewed-by: Junxing Chen <chenjunxin1@huawei.com>
Reviewed-by: Zhong Zhaohui <zhongzhaohui@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Qu Wenruo authored
mainline inclusion from mainline-5.2-rc1 commit ff2ac107 category: bugfix bugzilla: NA CVE: CVE-2019-19036 --------------------------- Commit 1ba98d08 ("Btrfs: detect corruption when non-root leaf has zero item") introduced comprehensive root owner checker. However it's pretty expensive tree search to locate the owner root, especially when it get reused by mandatory read and write time tree-checker. This patch will remove that check, and completely rely on owner based empty leaf check, which is much faster and still works fine for most case. And since we skip the old root owner check, now write time tree check can be merged with btrfs_check_leaf_full(). Signed-off-by:
Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Conflict:
fs/btrfs/tree-checker.c
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Zheng Bin authored
mainline inclusion from mainline-v5.6 commit d0c7feaf category: bugfix bugzilla: 30215 CVE: NA --------------------------- We recently used fuzz(hydra) to test XFS and automatically generate tmp.img(XFS v5 format, but some metadata is wrong) xfs_repair information(just one AG): agf_freeblks 0, counted 3224 in ag 0 agf_longest 536874136, counted 3224 in ag 0 sb_fdblocks 613, counted 3228 Test as follows: mount tmp.img tmpdir cp file1M tmpdir sync In 4.19-stable, sync will stuck, the reason is: xfs_mountfs xfs_check_summary_counts if ((!xfs_sb_version_haslazysbcount(&mp->m_sb) || XFS_LAST_UNMOUNT_WAS_CLEAN(mp)) && !xfs_fs_has_sickness(mp, XFS_SICK_FS_COUNTERS)) return 0; -->just return, incore sb_fdblocks still be 613 xfs_initialize_perag_data cp file1M tmpdir -->ok(write file to pagecache) sync -->stuck(write pagecache to disk) xfs_map_blocks xfs_iomap_write_allocate while (count_fsb != 0) { nimaps = 0; while (nimaps == 0) { --> endless loop nimaps = 1; xfs_bmapi_write(..., &nimaps) --> nimaps becomes 0 again xfs_bmapi_write xfs_bmap_alloc xfs_bmap_btalloc xfs_alloc_vextent xfs_alloc_fix_freelist xfs_alloc_space_available -->fail(agf_freeblks is 0) In linux-next, sync not stuck, cause commit c2b31643 ("xfs: use the latest extent at writeback delalloc conversion time") remove the above while, dmesg is as follows: [ 55.250114] XFS (loop0): page discard on page ffffea0008bc7380, inode 0x1b0c, offset 0. Users do not know why this page is discard, the better soultion is: 1. Like xfs_repair, make sure sb_fdblocks is equal to counted (xfs_initialize_perag_data did this, who is not called at this mount) 2. Add agf verify, if fail, will tell users to repair This patch use the second soultion. Signed-off-by:
Zheng Bin <zhengbin13@huawei.com>
Signed-off-by: Ren Xudong <renxudong1@huawei.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Cengiz Can authored
mainline inclusion from mainline-v5.6-rc4 commit 153031a3 category: bugfix bugzilla: 13690 CVE: CVE-2019-19768 ------------------------------------------------- There was a recent change in blktrace.c that added a RCU protection to `q->blk_trace` in order to fix a use-after-free issue during access. However the change missed an edge case that can lead to dereferencing of `bt` pointer even when it's NULL: Coverity static analyzer marked this as a FORWARD_NULL issue with CID 1460458. ``` /kernel/trace/blktrace.c: 1904 in sysfs_blk_trace_attr_store() 1898 ret = 0; 1899 if (bt == NULL) 1900 ret = blk_trace_setup_queue(q, bdev); 1901 1902 if (ret == 0) { 1903 if (attr == &dev_attr_act_mask) >>> CID 1460458: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "bt". 1904 bt->act_mask = value; 1905 else if (attr == &dev_attr_pid) 1906 bt->pid = value; 1907 else if (attr == &dev_attr_start_lba) 1908 bt->start_lba = value; 1909 else if (attr == &dev_attr_end_lba) ``` Added a reassignment with RCU annotation to fix the issue. Fixes: c780e86d ("blktrace: Protect q->blk_trace with RCU") Cc: stable@vger.kernel.org Reviewed-by:
Ming Lei <ming.lei@redhat.com>
Reviewed-by: Bob Liu <bob.liu@oracle.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Jan Kara authored
mainline inclusion from mainline-v5.6-rc4 commit c780e86d category: bugfix bugzilla: 13690 CVE: CVE-2019-19768 ------------------------------------------------- KASAN is reporting that __blk_add_trace() has a use-after-free issue when accessing q->blk_trace. Indeed the switching of block tracing (and thus eventual freeing of q->blk_trace) is completely unsynchronized with the currently running tracing and thus it can happen that the blk_trace structure is being freed just while __blk_add_trace() works on it. Protect accesses to q->blk_trace by RCU during tracing and make sure we wait for the end of RCU grace period when shutting down tracing. Luckily that is rare enough event that we can afford that. Note that postponing the freeing of blk_trace to an RCU callback should better be avoided as it could have unexpected user visible side-effects as debugfs files would be still existing for a short while block tracing has been shut down. Link: https://bugzilla.kernel.org/show_bug.cgi?id=205711 CC: stable@vger.kernel.org Reviewed-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Tested-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reported-by: Tristan Madani <tristmd@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Conflicts:
kernel/trace/blktrace.c
[yyl: adjust context]
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Zhang Xiaoxu authored
mainline inclusion from mainline-v5.6-rc4 commit 513dc792 category: bugfix bugzilla: 13690 CVE: CVE-2020-8647, CVE-2020-8649 ------------------------------------------------- When syzkaller tests, there is a UAF: BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr ffff880000100000 Read of size 2 by task syz-executor.1/16489 page:ffffea0000004000 count:0 mapcount:-127 mapping: (null) index:0x0 page flags: 0xfffff00000000() page dumped because: kasan: bad access detected CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: [<ffffffffb119f309>] dump_stack+0x1e/0x20 [<ffffffffb04af957>] kasan_report+0x577/0x950 [<ffffffffb04ae652>] __asan_load2+0x62/0x80 [<ffffffffb090f26d>] vgacon_invert_region+0x9d/0x110 [<ffffffffb0a39d95>] invert_screen+0xe5/0x470 [<ffffffffb0a21dcb>] set_selection+0x44b/0x12f0 [<ffffffffb0a3bfae>] tioclinux+0xee/0x490 [<ffffffffb0a1d114>] vt_ioctl+0xff4/0x2670 [<ffffffffb0a0089a>] tty_ioctl+0x46a/0x1a10 [<ffffffffb052db3d>] do_vfs_ioctl+0x5bd/0xc40 [<ffffffffb052e2f2>] SyS_ioctl+0x132/0x170 [<ffffffffb11c9b1b>] system_call_fastpath+0x22/0x27 Memory state around the buggy address: ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff It can be reproduce in the linux mainline by the program: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/ioctl.h> #include <linux/vt.h> struct tiocl_selection { unsigned short xs; /* X start */ unsigned short ys; /* Y start */ unsigned short xe; /* X end */ unsigned short ye; /* Y end */ unsigned short sel_mode; /* selection mode */ }; #define TIOCL_SETSEL 2 struct tiocl { unsigned char type; unsigned char pad; struct tiocl_selection sel; }; int main() { int fd = 0; const char *dev = "/dev/char/4:1"; struct vt_consize v = {0}; struct tiocl tioc = {0}; fd = open(dev, O_RDWR, 0); v.v_rows = 3346; ioctl(fd, VT_RESIZEX, &v); tioc.type = TIOCL_SETSEL; ioctl(fd, TIOCLINUX, &tioc); return 0; } When resize the screen, update the 'vc->vc_size_row' to the new_row_size, but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base' for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc the offset, it maybe larger than the vga_vram_size in vgacon driver, then bad access. Also, if set an larger screenbuf firstly, then set an more larger screenbuf, when copy old_origin to new_origin, a bad access may happen. So, If the screen size larger than vga_vram, resize screen should be failed. This alse fix CVE-2020-8649 and CVE-2020-8647. Linus pointed out that overflow checking seems absent. We're saved by the existing bounds checks in vc_do_resize() with rather strict limits: if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW) return -EINVAL; Fixes: 0aec4867 ("[PATCH] SVGATextMode fix") Reference: CVE-2020-8647 and CVE-2020-8649 Reported-by:
Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
[danvet: augment commit message to point out overflow safety]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 11, 2020
-
-
Richard Palethorpe authored
[ Upstream commit 0ace17d5 ] write_wakeup can happen in parallel with close/hangup where tty->disc_data is set to NULL and the netdevice is freed thus also freeing disc_data. write_wakeup accesses disc_data so we must prevent close from freeing the netdev while write_wakeup has a non-NULL view of tty->disc_data. We also need to make sure that accesses to disc_data are atomic. Which can all be done with RCU. This problem was found by Syzkaller on SLCAN, but the same issue is reproducible with the SLIP line discipline using an LTP test based on the Syzkaller reproducer. A fix which didn't use RCU was posted by Hillf Danton. Fixes: 661f7fda ("slip: Fix deadlock in write_wakeup") Fixes: a8e83b17 ("slcan: Port write_wakeup deadlock fix from slip") Reported-by:
<syzbot+017e491ae13c0068598a@syzkaller.appspotmail.com>
Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Tyler Hall <tylerwhall@gmail.com>
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Yang Yingliang authored
hulk inclusion category: bugfix bugzilla: 13690 CVE: CVE-2019-19462 ------------------------------------------------- alloc_percpu() may return NULL, which means chan->buf may be set to NULL. In that case, when we do *per_cpu_ptr(chan->buf, ...), we dereference an invalid pointer: BUG: Unable to handle kernel data access at 0x7dae0000 Faulting instruction address: 0xc0000000003f3fec ... NIP [c0000000003f3fec] relay_open+0x29c/0x600 LR [c0000000003f3fc0] relay_open+0x270/0x600 Call Trace: [c000000054353a70] [c0000000003f3fb4] relay_open+0x264/0x600 (unreliable) [c000000054353b00] [c000000000451764] __blk_trace_setup+0x254/0x600 [c000000054353bb0] [c000000000451b78] blk_trace_setup+0x68/0xa0 [c000000054353c10] [c0000000010da77c] sg_ioctl+0x7bc/0x2e80 [c000000054353cd0] [c000000000758cbc] do_vfs_ioctl+0x13c/0x1300 [c000000054353d90] [c000000000759f14] ksys_ioctl+0x94/0x130 [c000000054353de0] [c000000000759ff8] sys_ioctl+0x48/0xb0 [c000000054353e20] [c00000000000bcd0] system_call+0x5c/0x68 Check if alloc_percpu returns NULL. This was found by syzkaller both on x86 and powerpc, and the reproducer it found on powerpc is capable of hitting the issue as an unprivileged user. https://lore.kernel.org/lkml/20191219121256.26480-1-dja%40axtens.net/ Fixes: 017c59c0 ("relay: Use per CPU constructs for the relay channel buffer pointers") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Yang Yingliang authored
hulk inclusion category: bugfix bugzilla: 13690 CVE: CVE-2019-16230 ------------------------------------------------- check the alloc_workqueue return value in radeon_crtc_init() to avoid null-ptr-deref. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Navid Emamdoost authored
hulk inclusion category: bugfix bugzilla: NA CVE: CVE-2019-18814 --------------------------- In the implementation of aa_audit_rule_init(), when aa_label_parse() fails the allocated memory for rule is released using aa_audit_rule_free(). But after this release, the return statement tries to access the label field of the rule which results in use-after-free. Before releasing the rule, copy errNo and return it after release. Fixes: 52e8c380 ("apparmor: Fix memory leak of rule on error exit path") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- Mar 05, 2020
-
-
Cheng Jian authored
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:
Cheng Jian <cj.chengjian@huawei.com>
Reviewed-By: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-