Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921: fix possible AOOB issue in mt7921_mcu_tx_rate_report<br /> <br /> Fix possible array out of bound access in mt7921_mcu_tx_rate_report.<br /> Remove unnecessary varibable in mt7921_mcu_tx_rate_report

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: skip expectations for confirmed conntrack<br /> <br /> nft_ct_expect_obj_eval() calls nf_ct_ext_add() for a confirmed<br /> conntrack entry. However, nf_ct_ext_add() can only be called for<br /> !nf_ct_is_confirmed().<br /> <br /> [ 1825.349056] WARNING: CPU: 0 PID: 1279 at net/netfilter/nf_conntrack_extend.c:48 nf_ct_xt_add+0x18e/0x1a0 [nf_conntrack]<br /> [ 1825.351391] RIP: 0010:nf_ct_ext_add+0x18e/0x1a0 [nf_conntrack]<br /> [ 1825.351493] Code: 41 5c 41 5d 41 5e 41 5f c3 41 bc 0a 00 00 00 e9 15 ff ff ff ba 09 00 00 00 31 f6 4c 89 ff e8 69 6c 3d e9 eb 96 45 31 ed eb cd 0b e9 b1 fe ff ff e8 86 79 14 e9 eb bf 0f 1f 40 00 0f 1f 44 00<br /> [ 1825.351721] RSP: 0018:ffffc90002e1f1e8 EFLAGS: 00010202<br /> [ 1825.351790] RAX: 000000000000000e RBX: ffff88814f5783c0 RCX: ffffffffc0e4f887<br /> [ 1825.351881] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88814f578440<br /> [ 1825.351971] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88814f578447<br /> [ 1825.352060] R10: ffffed1029eaf088 R11: 0000000000000001 R12: ffff88814f578440<br /> [ 1825.352150] R13: ffff8882053f3a00 R14: 0000000000000000 R15: 0000000000000a20<br /> [ 1825.352240] FS: 00007f992261c900(0000) GS:ffff889faec00000(0000) knlGS:0000000000000000<br /> [ 1825.352343] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1825.352417] CR2: 000056070a4d1158 CR3: 000000015efe0000 CR4: 0000000000350ee0<br /> [ 1825.352508] Call Trace:<br /> [ 1825.352544] nf_ct_helper_ext_add+0x10/0x60 [nf_conntrack]<br /> [ 1825.352641] nft_ct_expect_obj_eval+0x1b8/0x1e0 [nft_ct]<br /> [ 1825.352716] nft_do_chain+0x232/0x850 [nf_tables]<br /> <br /> Add the ct helper extension only for unconfirmed conntrack. Skip rule<br /> evaluation if the ct helper extension does not exist. Thus, you can<br /> only create expectations from the first packet.<br /> <br /> It should be possible to remove this limitation by adding a new action<br /> to attach a generic ct helper to the first packet. Then, use this ct<br /> helper extension from follow up packets to create the ct expectation.<br /> <br /> While at it, add a missing check to skip the template conntrack too<br /> and remove check for IPCT_UNTRACK which is implicit to !ct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions<br /> <br /> Reported by syzbot:<br /> HEAD commit: 90c911ad Merge tag &amp;#39;fixes&amp;#39; of git://git.kernel.org/pub/scm..<br /> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master<br /> dashboard link: https://syzkaller.appspot.com/bug?extid=123aa35098fd3c000eb7<br /> compiler: Debian clang version 11.0.1-2<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline]<br /> BUG: KASAN: slab-out-of-bounds in fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732<br /> Read of size 8 at addr ffff8880145c78f8 by task syz-executor.4/17760<br /> <br /> CPU: 0 PID: 17760 Comm: syz-executor.4 Not tainted 5.12.0-rc8-syzkaller #0<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:79 [inline]<br /> dump_stack+0x202/0x31e lib/dump_stack.c:120<br /> print_address_description+0x5f/0x3b0 mm/kasan/report.c:232<br /> __kasan_report mm/kasan/report.c:399 [inline]<br /> kasan_report+0x15c/0x200 mm/kasan/report.c:416<br /> fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline]<br /> fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732<br /> fib6_nh_release+0x9a/0x430 net/ipv6/route.c:3536<br /> fib6_info_destroy_rcu+0xcb/0x1c0 net/ipv6/ip6_fib.c:174<br /> rcu_do_batch kernel/rcu/tree.c:2559 [inline]<br /> rcu_core+0x8f6/0x1450 kernel/rcu/tree.c:2794<br /> __do_softirq+0x372/0x7a6 kernel/softirq.c:345<br /> invoke_softirq kernel/softirq.c:221 [inline]<br /> __irq_exit_rcu+0x22c/0x260 kernel/softirq.c:422<br /> irq_exit_rcu+0x5/0x20 kernel/softirq.c:434<br /> sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100<br /> <br /> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632<br /> RIP: 0010:lock_acquire+0x1f6/0x720 kernel/locking/lockdep.c:5515<br /> Code: f6 84 24 a1 00 00 00 02 0f 85 8d 02 00 00 f7 c3 00 02 00 00 49 bd 00 00 00 00 00 fc ff df 74 01 fb 48 c7 44 24 40 0e 36 e0 45 c7 44 3d 00 00 00 00 00 4b c7 44 3d 09 00 00 00 00 43 c7 44 3d<br /> RSP: 0018:ffffc90009e06560 EFLAGS: 00000206<br /> RAX: 1ffff920013c0cc0 RBX: 0000000000000246 RCX: dffffc0000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc90009e066e0 R08: dffffc0000000000 R09: fffffbfff1f992b1<br /> R10: fffffbfff1f992b1 R11: 0000000000000000 R12: 0000000000000000<br /> R13: dffffc0000000000 R14: 0000000000000000 R15: 1ffff920013c0cb4<br /> rcu_lock_acquire+0x2a/0x30 include/linux/rcupdate.h:267<br /> rcu_read_lock include/linux/rcupdate.h:656 [inline]<br /> ext4_get_group_info+0xea/0x340 fs/ext4/ext4.h:3231<br /> ext4_mb_prefetch+0x123/0x5d0 fs/ext4/mballoc.c:2212<br /> ext4_mb_regular_allocator+0x8a5/0x28f0 fs/ext4/mballoc.c:2379<br /> ext4_mb_new_blocks+0xc6e/0x24f0 fs/ext4/mballoc.c:4982<br /> ext4_ext_map_blocks+0x2be3/0x7210 fs/ext4/extents.c:4238<br /> ext4_map_blocks+0xab3/0x1cb0 fs/ext4/inode.c:638<br /> ext4_getblk+0x187/0x6c0 fs/ext4/inode.c:848<br /> ext4_bread+0x2a/0x1c0 fs/ext4/inode.c:900<br /> ext4_append+0x1a4/0x360 fs/ext4/namei.c:67<br /> ext4_init_new_dir+0x337/0xa10 fs/ext4/namei.c:2768<br /> ext4_mkdir+0x4b8/0xc00 fs/ext4/namei.c:2814<br /> vfs_mkdir+0x45b/0x640 fs/namei.c:3819<br /> ovl_do_mkdir fs/overlayfs/overlayfs.h:161 [inline]<br /> ovl_mkdir_real+0x53/0x1a0 fs/overlayfs/dir.c:146<br /> ovl_create_real+0x280/0x490 fs/overlayfs/dir.c:193<br /> ovl_workdir_create+0x425/0x600 fs/overlayfs/super.c:788<br /> ovl_make_workdir+0xed/0x1140 fs/overlayfs/super.c:1355<br /> ovl_get_workdir fs/overlayfs/super.c:1492 [inline]<br /> ovl_fill_super+0x39ee/0x5370 fs/overlayfs/super.c:2035<br /> mount_nodev+0x52/0xe0 fs/super.c:1413<br /> legacy_get_tree+0xea/0x180 fs/fs_context.c:592<br /> vfs_get_tree+0x86/0x270 fs/super.c:1497<br /> do_new_mount fs/namespace.c:2903 [inline]<br /> path_mount+0x196f/0x2be0 fs/namespace.c:3233<br /> do_mount fs/namespace.c:3246 [inline]<br /> __do_sys_mount fs/namespace.c:3454 [inline]<br /> __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3431<br /> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x4665f9<br /> Code: ff ff c3 66 2e 0f 1f 84 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix freeing unallocated p2pmem<br /> <br /> In case p2p device was found but the p2p pool is empty, the nvme target<br /> is still trying to free the sgl from the p2p pool instead of the<br /> regular sgl pool and causing a crash (BUG() is called). Instead, assign<br /> the p2p_dev for the request only if it was allocated from p2p pool.<br /> <br /> This is the crash that was caused:<br /> <br /> [Sun May 30 19:13:53 2021] ------------[ cut here ]------------<br /> [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518!<br /> [Sun May 30 19:13:53 2021] invalid opcode: 0000 [#1] SMP PTI<br /> ...<br /> [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518!<br /> ...<br /> [Sun May 30 19:13:53 2021] RIP: 0010:gen_pool_free_owner+0xa8/0xb0<br /> ...<br /> [Sun May 30 19:13:53 2021] Call Trace:<br /> [Sun May 30 19:13:53 2021] ------------[ cut here ]------------<br /> [Sun May 30 19:13:53 2021] pci_free_p2pmem+0x2b/0x70<br /> [Sun May 30 19:13:53 2021] pci_p2pmem_free_sgl+0x4f/0x80<br /> [Sun May 30 19:13:53 2021] nvmet_req_free_sgls+0x1e/0x80 [nvmet]<br /> [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518!<br /> [Sun May 30 19:13:53 2021] nvmet_rdma_release_rsp+0x4e/0x1f0 [nvmet_rdma]<br /> [Sun May 30 19:13:53 2021] nvmet_rdma_send_done+0x1c/0x60 [nvmet_rdma]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix memory leak in ext4_mb_init_backend on error path.<br /> <br /> Fix a memory leak discovered by syzbot when a file system is corrupted<br /> with an illegally large s_log_groups_per_flex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: abort in rename_exchange if we fail to insert the second ref<br /> <br /> Error injection stress uncovered a problem where we&amp;#39;d leave a dangling<br /> inode ref if we failed during a rename_exchange. This happens because<br /> we insert the inode ref for one side of the rename, and then for the<br /> other side. If this second inode ref insert fails we&amp;#39;ll leave the first<br /> one dangling and leave a corrupt file system behind. Fix this by<br /> aborting if we did the insert for the first inode ref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kvm: Teardown PV features on boot CPU as well<br /> <br /> Various PV features (Async PF, PV EOI, steal time) work through memory<br /> shared with hypervisor and when we restore from hibernation we must<br /> properly teardown all these features to make sure hypervisor doesn&amp;#39;t<br /> write to stale locations after we jump to the previously hibernated kernel<br /> (which can try to place anything there). For secondary CPUs the job is<br /> already done by kvm_cpu_down_prepare(), register syscore ops to do<br /> the same for boot CPU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kvm: Disable kvmclock on all CPUs on shutdown<br /> <br /> Currenly, we disable kvmclock from machine_shutdown() hook and this<br /> only happens for boot CPU. We need to disable it for all CPUs to<br /> guard against memory corruption e.g. on restore from hibernate.<br /> <br /> Note, writing &amp;#39;0&amp;#39; to kvmclock MSR doesn&amp;#39;t clear memory location, it<br /> just prevents hypervisor from updating the location so for the short<br /> while after write and while CPU is still alive, the clock remains usable<br /> and correct so we don&amp;#39;t need to switch to some other clocksource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> neighbour: allow NUD_NOARP entries to be forced GCed<br /> <br /> IFF_POINTOPOINT interfaces use NUD_NOARP entries for IPv6. It&amp;#39;s possible to<br /> fill up the neighbour table with enough entries that it will overflow for<br /> valid connections after that.<br /> <br /> This behaviour is more prevalent after commit 58956317c8de ("neighbor:<br /> Improve garbage collection") is applied, as it prevents removal from<br /> entries that are not NUD_FAILED, unless they are more than 5s old.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netback: take a reference to the RX task thread<br /> <br /> Do this in order to prevent the task from being freed if the thread<br /> returns (which can be triggered by the frontend) before the call to<br /> kthread_stop done as part of the backend tear down. Not taking the<br /> reference will lead to a use-after-free in that scenario. Such<br /> reference was taken before but dropped as part of the rework done in<br /> 2ac061ce97f4.<br /> <br /> Reintroduce the reference taking and add a comment this time<br /> explaining why it&amp;#39;s needed.<br /> <br /> This is XSA-374 / CVE-2021-28691.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed<br /> <br /> We got follow bug_on when run fsstress with injecting IO fault:<br /> [130747.323114] kernel BUG at fs/ext4/extents_status.c:762!<br /> [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP<br /> ......<br /> [130747.334329] Call trace:<br /> [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4]<br /> [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4]<br /> [130747.335368] ext4_find_extent+0x300/0x330 [ext4]<br /> [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4]<br /> [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4]<br /> [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4]<br /> [130747.336995] ext4_readpage+0x54/0x100 [ext4]<br /> [130747.337359] generic_file_buffered_read+0x410/0xae8<br /> [130747.337767] generic_file_read_iter+0x114/0x190<br /> [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4]<br /> [130747.338556] __vfs_read+0x11c/0x188<br /> [130747.338851] vfs_read+0x94/0x150<br /> [130747.339110] ksys_read+0x74/0xf0<br /> <br /> This patch&amp;#39;s modification is according to Jan Kara&amp;#39;s suggestion in:<br /> https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/<br /> "I see. Now I understand your patch. Honestly, seeing how fragile is trying<br /> to fix extent tree after split has failed in the middle, I would probably<br /> go even further and make sure we fix the tree properly in case of ENOSPC<br /> and EDQUOT (those are easily user triggerable). Anything else indicates a<br /> HW problem or fs corruption so I&amp;#39;d rather leave the extent tree as is and<br /> don&amp;#39;t try to fix it (which also means we will not create overlapping<br /> extents)."