- Kernel - mailweb.openeuler.org

[PATCH] f2fs: fix to do sanity check on last xattr entry in __f2fs_setxattr()
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Chao Yu <chao(a)kernel.org> mainline inclusion from mainline-v5.17 commit 5598b24efaf4892741c798b425d543e4bed357a1 category: bugfix CVE: CVE-2021-45469 -------------------------------- As Wenqing Liu reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215235 - Overview page fault in f2fs_setxattr() when mount and operate on corrupted image - Reproduce tested on kernel 5.16-rc3, 5.15.X under root 1. unzip tmp7.zip 2. ./single.sh f2fs 7 Sometimes need to run the script several times - Kernel dump loop0: detected capacity change from 0 to 131072 F2FS-fs (loop0): Found nat_bits in checkpoint F2FS-fs (loop0): Mounted with checkpoint version = 7548c2ee BUG: unable to handle page fault for address: ffffe47bc7123f48 RIP: 0010:kfree+0x66/0x320 Call Trace: __f2fs_setxattr+0x2aa/0xc00 [f2fs] f2fs_setxattr+0xfa/0x480 [f2fs] __f2fs_set_acl+0x19b/0x330 [f2fs] __vfs_removexattr+0x52/0x70 __vfs_removexattr_locked+0xb1/0x140 vfs_removexattr+0x56/0x100 removexattr+0x57/0x80 path_removexattr+0xa3/0xc0 __x64_sys_removexattr+0x17/0x20 do_syscall_64+0x37/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is in __f2fs_setxattr(), we missed to do sanity check on last xattr entry, result in out-of-bound memory access during updating inconsistent xattr data of target inode. After the fix, it can detect such xattr inconsistency as below: F2FS-fs (loop11): inode (7) has invalid last xattr entry, entry_size: 60676 F2FS-fs (loop11): inode (8) has corrupted xattr F2FS-fs (loop11): inode (8) has corrupted xattr F2FS-fs (loop11): inode (8) has invalid last xattr entry, entry_size: 47736 Cc: stable(a)vger.kernel.org Reported-by: Wenqing Liu <wenqingliu0120(a)gmail.com> Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/f2fs/xattr.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c index 90d0d305f6a36..b55d0920e777c 100644 --- a/fs/f2fs/xattr.c +++ b/fs/f2fs/xattr.c @@ -657,8 +657,17 @@ static int __f2fs_setxattr(struct inode *inode, int index, } last = here; - while (!IS_XATTR_LAST_ENTRY(last)) + while (!IS_XATTR_LAST_ENTRY(last)) { + if ((void *)(last) + sizeof(__u32) > last_base_addr || + (void *)XATTR_NEXT_ENTRY(last) > last_base_addr) { + f2fs_err(F2FS_I_SB(inode), "inode (%lu) has invalid last xattr entry, entry_size: %zu", + inode->i_ino, ENTRY_SIZE(last)); + set_sbi_flag(F2FS_I_SB(inode), SBI_NEED_FSCK); + error = -EFSCORRUPTED; + goto exit; + } last = XATTR_NEXT_ENTRY(last); + } newsize = XATTR_ALIGN(sizeof(struct f2fs_xattr_entry) + len + size); -- 2.25.1

1 0

[PATCH] mwifiex: Fix skb_over_panic in mwifiex_usb_recv()
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Zekun Shen <bruceshenzk(a)gmail.com> mainline inclusion from mainline-v5.17 commit 04d80663f67ccef893061b49ec8a42ff7045ae84 category: bugfix CVE: CVE-2021-43976 -------------------------------- Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic. The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input. Attached is the panic report from fuzzing. skbuff: skb_over_panic: text:000000003bf1b5fa len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev:<NULL> kernel BUG at net/core/skbuff.c:109! invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: <IRQ> ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 </IRQ> Reported-by: Brendan Dolan-Gavitt <brendandg(a)nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Link: https://lore.kernel.org/r/YX4CqjfRcTa6bVL+@Zekuns-MBP-16.fios-router.home Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/net/wireless/marvell/mwifiex/usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c index d445acc4786b7..22a42eb0cc0ac 100644 --- a/drivers/net/wireless/marvell/mwifiex/usb.c +++ b/drivers/net/wireless/marvell/mwifiex/usb.c @@ -130,7 +130,8 @@ static int mwifiex_usb_recv(struct mwifiex_adapter *adapter, default: mwifiex_dbg(adapter, ERROR, "unknown recv_type %#x\n", recv_type); - return -1; + ret = -1; + goto exit_restore_skb; } break; case MWIFIEX_USB_EP_DATA: -- 2.25.1

1 0

[PATCH openEuler-5.10 01/87] kvm: SMM: fix losing SMI problem
by Zheng Zengkai 30 Dec '21

30 Dec '21

From: xulei <stone.xulei(a)huawei.com> virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4NP0K CVE: NA ------------------- fix losing SMI problem Signed-off-by: xulei <stone.xulei(a)huawei.com> Signed-off-by: Jingyi Wang <wangjingyi11(a)huawei.com> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Reviewed-by: Wei Li <liwei391(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- arch/x86/kvm/x86.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 12db47c8bd3f..e33414f36dba 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4227,6 +4227,11 @@ static int kvm_vcpu_ioctl_nmi(struct kvm_vcpu *vcpu) static int kvm_vcpu_ioctl_smi(struct kvm_vcpu *vcpu) { + if (is_smm(vcpu)) { + vcpu->arch.hflags &= ~HF_SMM_MASK; + vcpu->arch.smi_pending = 0; + } + kvm_make_request(KVM_REQ_SMI, vcpu); return 0; -- 2.20.1

1 86

[PATCH openEuler-1.0-LTS] mm/page_alloc: Use cmdline to disable "place pages to tail"
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Peng Liu <liupeng256(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4EG0R CVE: NA ----------------------------------------------- Add cmdline to disable "place pages to tail" when online memory. Signed-off-by: Peng Liu <liupeng256(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- .../admin-guide/kernel-parameters.txt | 9 +++++++ mm/page_alloc.c | 27 ++++++++++++++----- 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 425015359b5ce..420f7317aa6af 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1254,6 +1254,15 @@ Warning: use of this parameter will taint the kernel and may cause unknown problems. + fpi_to_tail=off + [KNL] Place pages to front in __free_pages_core(). + This kernel start-up parameter can be just used as + "fpi_to_tail=off", which means memory is online to + the front of freelist. Dynamic open is not supportted, + in other words, "fpi_to_tail=on" will be ignored by + kernel. This is just an ugly solution for circumvention + for some latent bugs revealed by "place pages to tail". + ftrace=[tracer] [FTRACE] will set and start the specified tracer as early as possible in order to facilitate early diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 935435e03cdd4..4cad86f1e3a91 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -102,6 +102,17 @@ typedef int __bitwise fpi_t; */ #define FPI_TO_TAIL ((__force fpi_t)BIT(1)) +static bool fpi_to_tail = true; + +static int __init early_fpi_to_tail(char *str) +{ + if (str && !strcmp(str, "off")) + fpi_to_tail = false; + + return 0; +} +early_param("fpi_to_tail", early_fpi_to_tail); + /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ static DEFINE_MUTEX(pcp_batch_high_lock); #define MIN_PERCPU_PAGELIST_FRACTION (8) @@ -1342,12 +1353,16 @@ void __free_pages_core(struct page *page, unsigned int order) } __ClearPageReserved(p); set_page_count(p, 0); - - /* - * Bypass PCP and place fresh pages right to the tail, primarily - * relevant for memory onlining. - */ - __free_pages_ok(page, order, FPI_TO_TAIL); + if (fpi_to_tail) { + /* + * Bypass PCP and place fresh pages right to the tail, primarily + * relevant for memory onlining. + */ + __free_pages_ok(page, order, FPI_TO_TAIL); + } else { + set_page_refcounted(page); + __free_pages(page, order); + } } #if defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID) || \ -- 2.25.1

1 0

[PATCH OLK-5.10 0/3] Add three modifications
by Yanling Song 30 Dec '21

30 Dec '21

Add three modifications. 1.RSS initialization process optimization 2.Attribute negotiation and optimization. 3.The reset command flags modification. Yanling Song (3): net/spnic:RSS initialization process optimization net/spnic:Attribute negotiation and optimization. net/spnic:The reset command flags modification. .../net/ethernet/ramaxel/spnic/hw/sphw_hw.h | 28 ++++----- .../ethernet/ramaxel/spnic/hw/sphw_hwdev.c | 9 ++- .../ethernet/ramaxel/spnic/hw/sphw_hwdev.h | 2 + .../net/ethernet/ramaxel/spnic/spnic_main.c | 22 +++---- .../ramaxel/spnic/spnic_mgmt_interface.h | 12 ---- .../ethernet/ramaxel/spnic/spnic_nic_cfg.c | 57 ++++++++++++------- .../ethernet/ramaxel/spnic/spnic_nic_cfg.h | 19 +------ .../ethernet/ramaxel/spnic/spnic_nic_dev.h | 2 + .../net/ethernet/ramaxel/spnic/spnic_rss.c | 16 +----- .../ethernet/ramaxel/spnic/spnic_rss_cfg.c | 57 ------------------- 10 files changed, 70 insertions(+), 154 deletions(-) -- 2.23.0

1 3

[PATCH openEuler-1.0-LTS] scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Can Guo <cang(a)codeaurora.org> mainline inclusion from mainline-v5.11-rc4 commit 35fc4cd34426c242ab015ef280853b7bff101f48 category: bugfix bugzilla: NA CVE: CVE-2021-39657 ----------------------------------------------- Users can initiate resets to specific SCSI device/target/host through IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host _reset_handler() callbacks is initialized with a request whose tag is -1. In this case it is not right for eh_device_reset_handler() callback to count on the LUN get from hba->lrb[-1]. Fix it by getting LUN from the SCSI device associated with the SCSI cmd. Link: https://lore.kernel.org/r/1609157080-26283-1-git-send-email-cang@codeaurora… Reviewed-by: Avri Altman <avri.altman(a)wdc.com> Reviewed-by: Stanley Chu <stanley.chu(a)mediatek.com> Signed-off-by: Can Guo <cang(a)codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Ye Bin <yebin10(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/scsi/ufs/ufshcd.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 3601e770da162..3d9bfa5207689 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -5752,19 +5752,16 @@ static int ufshcd_eh_device_reset_handler(struct scsi_cmnd *cmd) { struct Scsi_Host *host; struct ufs_hba *hba; - unsigned int tag; u32 pos; int err; - u8 resp = 0xF; - struct ufshcd_lrb *lrbp; + u8 resp = 0xF, lun; unsigned long flags; host = cmd->device->host; hba = shost_priv(host); - tag = cmd->request->tag; - lrbp = &hba->lrb[tag]; - err = ufshcd_issue_tm_cmd(hba, lrbp->lun, 0, UFS_LOGICAL_RESET, &resp); + lun = ufshcd_scsi_to_upiu_lun(cmd->device->lun); + err = ufshcd_issue_tm_cmd(hba, lun, 0, UFS_LOGICAL_RESET, &resp); if (err || resp != UPIU_TASK_MANAGEMENT_FUNC_COMPL) { if (!err) err = resp; @@ -5773,7 +5770,7 @@ static int ufshcd_eh_device_reset_handler(struct scsi_cmnd *cmd) /* clear the commands that were pending for corresponding LUN */ for_each_set_bit(pos, &hba->outstanding_reqs, hba->nutrs) { - if (hba->lrb[pos].lun == lrbp->lun) { + if (hba->lrb[pos].lun == lun) { err = ufshcd_clear_cmd(hba, pos); if (err) break; -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] ext4: fix an use-after-free issue about data=journal writeback mode
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Zhang Yi <yi.zhang(a)huawei.com> hulk inclusion category: bugfix bugzilla: 185944, https://gitee.com/openeuler/kernel/issues/I4OP92 CVE: NA --------------------------- Our syzkaller report an use-after-free issue that accessing the freed buffer_head on the writeback page in __ext4_journalled_writepage(). The problem is that if there was a truncate racing with the data=journalled writeback procedure, the writeback length could become zero and bget_one() refuse to get buffer_head's refcount, then the truncate procedure release buffer once we drop page lock, finally, the last ext4_walk_page_buffers() trigger the use-after-free problem. sync truncate ext4_sync_file() file_write_and_wait_range() ext4_setattr(0) inode->i_size = 0 ext4_writepage() len = 0 __ext4_journalled_writepage() page_bufs = page_buffers(page) ext4_walk_page_buffers(bget_one) <- does not get refcount do_invalidatepage() free_buffer_head() ext4_walk_page_buffers(page_bufs) <- trigger use-after-free After commit bdf96838aea6 ("ext4: fix race between truncate and __ext4_journalled_writepage()"), we have already handled the racing case, so the bget_one() and bput_one() are not needed. So this patch simply remove these hunk, and recheck the i_size to make it safe. Fixes: bdf96838aea6 ("ext4: fix race between truncate and __ext4_journalled_writepage()") Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: yangerkun <yangerkun(a)huawei.com> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/ext4/inode.c | 35 ++++++++++------------------------- 1 file changed, 10 insertions(+), 25 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 6213816056cd6..e106a9317b429 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1962,28 +1962,16 @@ int ext4_da_get_block_prep(struct inode *inode, sector_t iblock, return 0; } -static int bget_one(handle_t *handle, struct buffer_head *bh) -{ - get_bh(bh); - return 0; -} - -static int bput_one(handle_t *handle, struct buffer_head *bh) -{ - put_bh(bh); - return 0; -} - static int __ext4_journalled_writepage(struct page *page, unsigned int len) { struct address_space *mapping = page->mapping; struct inode *inode = mapping->host; - struct buffer_head *page_bufs = NULL; handle_t *handle = NULL; int ret = 0, err = 0; int inline_data = ext4_has_inline_data(inode); struct buffer_head *inode_bh = NULL; + loff_t size; ClearPageChecked(page); @@ -1993,14 +1981,6 @@ static int __ext4_journalled_writepage(struct page *page, inode_bh = ext4_journalled_write_inline_data(inode, len, page); if (inode_bh == NULL) goto out; - } else { - page_bufs = page_buffers(page); - if (!page_bufs) { - BUG(); - goto out; - } - ext4_walk_page_buffers(handle, page_bufs, 0, len, - NULL, bget_one); } /* * We need to release the page lock before we start the @@ -2021,7 +2001,8 @@ static int __ext4_journalled_writepage(struct page *page, lock_page(page); put_page(page); - if (page->mapping != mapping) { + size = i_size_read(inode); + if (page->mapping != mapping || page_offset(page) > size) { /* The page got truncated from under us */ ext4_journal_stop(handle); ret = 0; @@ -2031,6 +2012,13 @@ static int __ext4_journalled_writepage(struct page *page, if (inline_data) { ret = ext4_mark_inode_dirty(handle, inode); } else { + struct buffer_head *page_bufs = page_buffers(page); + + if (page->index == size >> PAGE_SHIFT) + len = size & ~PAGE_MASK; + else + len = PAGE_SIZE; + ret = ext4_walk_page_buffers(handle, page_bufs, 0, len, NULL, do_journal_get_write_access); @@ -2048,9 +2036,6 @@ static int __ext4_journalled_writepage(struct page *page, out: unlock_page(page); out_no_pagelock: - if (!inline_data && page_bufs) - ext4_walk_page_buffers(NULL, page_bufs, 0, len, - NULL, bput_one); brelse(inode_bh); return ret; } -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] netdevsim: Zero-initialize memory for new map's value in function nsim_bpf_map_alloc
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Haimin Zhang <tcs.kernel(a)gmail.com> mainline inclusion from mainline-5.16-rc6 commit 481221775d53d6215a6e5e9ce1cce6d2b4ab9a46 category: bugfix CVE: CVE-2021-4135 -------------------------------- Zero-initialize memory for new map's value in function nsim_bpf_map_alloc since it may cause a potential kernel information leak issue, as follows: 1. nsim_bpf_map_alloc calls nsim_map_alloc_elem to allocate elements for a new map. 2. nsim_map_alloc_elem uses kmalloc to allocate map's value, but doesn't zero it. 3. A user application can use IOCTL BPF_MAP_LOOKUP_ELEM to get specific element's information in the map. 4. The kernel function map_lookup_elem will call bpf_map_copy_value to get the information allocated at step-2, then use copy_to_user to copy to the user buffer. This can only leak information for an array map. Fixes: 395cacb5f1a0 ("netdevsim: bpf: support fake map offload") Suggested-by: Jakub Kicinski <kuba(a)kernel.org> Acked-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Haimin Zhang <tcs.kernel(a)gmail.com> Link: https://lore.kernel.org/r/20211215111530.72103-1-tcs.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/net/netdevsim/bpf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/netdevsim/bpf.c b/drivers/net/netdevsim/bpf.c index 81444208b2162..12f100392ed11 100644 --- a/drivers/net/netdevsim/bpf.c +++ b/drivers/net/netdevsim/bpf.c @@ -493,6 +493,7 @@ nsim_bpf_map_alloc(struct netdevsim *ns, struct bpf_offloaded_map *offmap) goto err_free; key = nmap->entry[i].key; *key = i; + memset(nmap->entry[i].value, 0, offmap->map.value_size); } } -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS 1/7] bpf: Fix up register-based shifts in interpreter to silence KUBSAN
by Yang Yingliang 30 Dec '21

30 Dec '21

From: Daniel Borkmann <daniel(a)iogearbox.net> mainline inclusion from mainline-v5.12 commit 28131e9d933339a92f78e7ab6429f4aaaa07061c category: bugfix bugzilla: NA CVE: NA ----------------------------------------------------------------------- syzbot reported a shift-out-of-bounds that KUBSAN observed in the interpreter: [...] UBSAN: shift-out-of-bounds in kernel/bpf/core.c:1420:2 shift exponent 255 is too large for 64-bit type 'long long unsigned int' CPU: 1 PID: 11097 Comm: syz-executor.4 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 ___bpf_prog_run.cold+0x19/0x56c kernel/bpf/core.c:1420 __bpf_prog_run32+0x8f/0xd0 kernel/bpf/core.c:1735 bpf_dispatcher_nop_func include/linux/bpf.h:644 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:624 [inline] bpf_prog_run_clear_cb include/linux/filter.h:755 [inline] run_filter+0x1a1/0x470 net/packet/af_packet.c:2031 packet_rcv+0x313/0x13e0 net/packet/af_packet.c:2104 dev_queue_xmit_nit+0x7c2/0xa90 net/core/dev.c:2387 xmit_one net/core/dev.c:3588 [inline] dev_hard_start_xmit+0xad/0x920 net/core/dev.c:3609 __dev_queue_xmit+0x2121/0x2e00 net/core/dev.c:4182 __bpf_tx_skb net/core/filter.c:2116 [inline] __bpf_redirect_no_mac net/core/filter.c:2141 [inline] __bpf_redirect+0x548/0xc80 net/core/filter.c:2164 ____bpf_clone_redirect net/core/filter.c:2448 [inline] bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2420 ___bpf_prog_run+0x34e1/0x77d0 kernel/bpf/core.c:1523 __bpf_prog_run512+0x99/0xe0 kernel/bpf/core.c:1737 bpf_dispatcher_nop_func include/linux/bpf.h:644 [inline] bpf_test_run+0x3ed/0xc50 net/bpf/test_run.c:50 bpf_prog_test_run_skb+0xabc/0x1c50 net/bpf/test_run.c:582 bpf_prog_test_run kernel/bpf/syscall.c:3127 [inline] __do_sys_bpf+0x1ea9/0x4f00 kernel/bpf/syscall.c:4406 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae [...] Generally speaking, KUBSAN reports from the kernel should be fixed. However, in case of BPF, this particular report caused concerns since the large shift is not wrong from BPF point of view, just undefined. In the verifier, K-based shifts that are >= {64,32} (depending on the bitwidth of the instruction) are already rejected. The register-based cases were not given their content might not be known at verification time. Ideas such as verifier instruction rewrite with an additional AND instruction for the source register were brought up, but regularly rejected due to the additional runtime overhead they incur. As Edward Cree rightly put it: Shifts by more than insn bitness are legal in the BPF ISA; they are implementation-defined behaviour [of the underlying architecture], rather than UB, and have been made legal for performance reasons. Each of the JIT backends compiles the BPF shift operations to machine instructions which produce implementation-defined results in such a case; the resulting contents of the register may be arbitrary but program behaviour as a whole remains defined. Guard checks in the fast path (i.e. affecting JITted code) will thus not be accepted. The case of division by zero is not truly analogous here, as division instructions on many of the JIT-targeted architectures will raise a machine exception / fault on division by zero, whereas (to the best of my knowledge) none will do so on an out-of-bounds shift. Given the KUBSAN report only affects the BPF interpreter, but not JITs, one solution is to add the ANDs with 63 or 31 into ___bpf_prog_run(). That would make the shifts defined, and thus shuts up KUBSAN, and the compiler would optimize out the AND on any CPU that interprets the shift amounts modulo the width anyway (e.g., confirmed from disassembly that on x86-64 and arm64 the generated interpreter code is the same before and after this fix). The BPF interpreter is slow path, and most likely compiled out anyway as distros select BPF_JIT_ALWAYS_ON to avoid speculative execution of BPF instructions by the interpreter. Given the main argument was to avoid sacrificing performance, the fact that the AND is optimized away from compiler for mainstream archs helps as well as a solution moving forward. Also add a comment on LSH/RSH/ARSH translation for JIT authors to provide guidance when they see the ___bpf_prog_run() interpreter code and use it as a model for a new JIT backend. Reported-by: syzbot+bed360704c521841c85d(a)syzkaller.appspotmail.com Reported-by: Kurt Manucredo <fuzzybritches0(a)gmail.com> Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> Co-developed-by: Eric Biggers <ebiggers(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Tested-by: syzbot+bed360704c521841c85d(a)syzkaller.appspotmail.com Cc: Edward Cree <ecree.xilinx(a)gmail.com> Link: https://lore.kernel.org/bpf/0000000000008f912605bd30d5d7@google.com Link: https://lore.kernel.org/bpf/bac16d8d-c174-bdc4-91bd-bfa62b410190@gmail.com conflicts: kernel/bpf/core.c Signed-off-by: He Fengqing <hefengqing(a)huawei.com> Reviewed-by: Kuohai Xu <xukuohai(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/bpf/core.c | 59 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 42 insertions(+), 17 deletions(-) diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index 641622b65de44..625edbc8360de 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -1100,29 +1100,54 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) select_insn: goto *jumptable[insn->code]; - /* ALU */ -#define ALU(OPCODE, OP) \ - ALU64_##OPCODE##_X: \ - DST = DST OP SRC; \ - CONT; \ - ALU_##OPCODE##_X: \ - DST = (u32) DST OP (u32) SRC; \ - CONT; \ - ALU64_##OPCODE##_K: \ - DST = DST OP IMM; \ - CONT; \ - ALU_##OPCODE##_K: \ - DST = (u32) DST OP (u32) IMM; \ + /* Explicitly mask the register-based shift amounts with 63 or 31 + * to avoid undefined behavior. Normally this won't affect the + * generated code, for example, in case of native 64 bit archs such + * as x86-64 or arm64, the compiler is optimizing the AND away for + * the interpreter. In case of JITs, each of the JIT backends compiles + * the BPF shift operations to machine instructions which produce + * implementation-defined results in such a case; the resulting + * contents of the register may be arbitrary, but program behaviour + * as a whole remains defined. In other words, in case of JIT backends, + * the AND must /not/ be added to the emitted LSH/RSH/ARSH translation. + */ + /* ALU (shifts) */ +#define SHT(OPCODE, OP) \ + ALU64_##OPCODE##_X: \ + DST = DST OP (SRC & 63); \ + CONT; \ + ALU_##OPCODE##_X: \ + DST = (u32) DST OP ((u32) SRC & 31); \ + CONT; \ + ALU64_##OPCODE##_K: \ + DST = DST OP IMM; \ + CONT; \ + ALU_##OPCODE##_K: \ + DST = (u32) DST OP (u32) IMM; \ + CONT; + /* ALU (rest) */ +#define ALU(OPCODE, OP) \ + ALU64_##OPCODE##_X: \ + DST = DST OP SRC; \ + CONT; \ + ALU_##OPCODE##_X: \ + DST = (u32) DST OP (u32) SRC; \ + CONT; \ + ALU64_##OPCODE##_K: \ + DST = DST OP IMM; \ + CONT; \ + ALU_##OPCODE##_K: \ + DST = (u32) DST OP (u32) IMM; \ CONT; - ALU(ADD, +) ALU(SUB, -) ALU(AND, &) ALU(OR, |) - ALU(LSH, <<) - ALU(RSH, >>) ALU(XOR, ^) ALU(MUL, *) + SHT(LSH, <<) + SHT(RSH, >>) +#undef SHT #undef ALU ALU_NEG: DST = (u32) -DST; @@ -1147,7 +1172,7 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) insn++; CONT; ALU64_ARSH_X: - (*(s64 *) &DST) >>= SRC; + (*(s64 *) &DST) >>= (SRC & 63); CONT; ALU64_ARSH_K: (*(s64 *) &DST) >>= IMM; -- 2.25.1

1 6

[PATCH openEuler-1.0-LTS 00/14] fixes CVEs for xen
by Yang Yingliang 30 Dec '21

30 Dec '21

patch #1 ~ #9 prepare for fix CVEs patch #10 ~ #14 fixes: CVE-2021-28711 CVE-2021-28712 CVE-2021-28713 CVE-2021-28714 CVE-2021-28715 Juergen Gross (14): xen/netback: avoid race in xenvif_rx_ring_slots_available() xen: sync include/xen/interface/io/ring.h with Xen's newest version xen/blkfront: read response from backend only once xen/blkfront: don't take local copy of a request from the ring page xen/blkfront: don't trust the backend response data blindly xen/netfront: read response from backend only once xen/netfront: don't read data from request on the ring page xen/netfront: disentangle tx_skb_freelist xen/netfront: don't trust the backend response data blindly xen/blkfront: harden blkfront against event channel storms xen/netfront: harden netfront against event channel storms xen/console: harden hvc_xen against event channel storms xen/netback: fix rx queue stall detection xen/netback: don't queue unlimited number of packages drivers/block/xen-blkfront.c | 141 ++++++++---- drivers/net/xen-netback/common.h | 1 + drivers/net/xen-netback/rx.c | 70 ++++-- drivers/net/xen-netfront.c | 372 ++++++++++++++++++++----------- drivers/tty/hvc/hvc_xen.c | 30 ++- include/xen/interface/io/ring.h | 293 +++++++++++++----------- 6 files changed, 575 insertions(+), 332 deletions(-) -- 2.25.1

1 14