Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Make sure GHCB is mapped before updating<br /> <br /> Access to the GHCB is mainly in the VMGEXIT path and it is known that the<br /> GHCB will be mapped. But there are two paths where it is possible the GHCB<br /> might not be mapped.<br /> <br /> The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform<br /> the caller of the AP Reset Hold NAE event that a SIPI has been delivered.<br /> However, if a SIPI is performed without a corresponding AP Reset Hold,<br /> then the GHCB might not be mapped (depending on the previous VMEXIT),<br /> which will result in a NULL pointer dereference.<br /> <br /> The svm_complete_emulated_msr() routine will update the GHCB to inform<br /> the caller of a RDMSR/WRMSR operation about any errors. While it is likely<br /> that the GHCB will be mapped in this situation, add a safe guard<br /> in this path to be certain a NULL pointer dereference is not encountered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: Fix memory leak on object td<br /> <br /> Two error return paths are neglecting to free allocated object td,<br /> causing a memory leak. Fix this by returning via the error return<br /> path that securely kfree&amp;#39;s td.<br /> <br /> Fixes clang scan-build warning:<br /> security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential<br /> memory leak [unix.Malloc]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Only allow init netns to set default tcp cong to a restricted algo<br /> <br /> tcp_set_default_congestion_control() is netns-safe in that it writes<br /> to &amp;net-&gt;ipv4.tcp_congestion_control, but it also sets<br /> ca-&gt;flags |= TCP_CONG_NON_RESTRICTED which is not namespaced.<br /> This has the unintended side-effect of changing the global<br /> net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it<br /> is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control<br /> readonly in non-init netns")<br /> <br /> Resolve this netns "leak" by only allowing the init netns to set the<br /> default algorithm to one that is restricted. This restriction could be<br /> removed if tcp_allowed_congestion_control were namespace-ified in the<br /> future.<br /> <br /> This bug was uncovered with<br /> https://github.com/JonathonReinhart/linux-netns-sysctl-verify

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: memcontrol: slab: fix obtain a reference to a freeing memcg<br /> <br /> Patch series "Use obj_cgroup APIs to charge kmem pages", v5.<br /> <br /> Since Roman&amp;#39;s series "The new cgroup slab memory controller" applied.<br /> All slab objects are charged with the new APIs of obj_cgroup. The new<br /> APIs introduce a struct obj_cgroup to charge slab objects. It prevents<br /> long-living objects from pinning the original memory cgroup in the<br /> memory. But there are still some corner objects (e.g. allocations<br /> larger than order-1 page on SLUB) which are not charged with the new<br /> APIs. Those objects (include the pages which are allocated from buddy<br /> allocator directly) are charged as kmem pages which still hold a<br /> reference to the memory cgroup.<br /> <br /> E.g. We know that the kernel stack is charged as kmem pages because the<br /> size of the kernel stack can be greater than 2 pages (e.g. 16KB on<br /> x86_64 or arm64). If we create a thread (suppose the thread stack is<br /> charged to memory cgroup A) and then move it from memory cgroup A to<br /> memory cgroup B. Because the kernel stack of the thread hold a<br /> reference to the memory cgroup A. The thread can pin the memory cgroup<br /> A in the memory even if we remove the cgroup A. If we want to see this<br /> scenario by using the following script. We can see that the system has<br /> added 500 dying cgroups (This is not a real world issue, just a script<br /> to show that the large kmallocs are charged as kmem pages which can pin<br /> the memory cgroup in the memory).<br /> <br /> #!/bin/bash<br /> <br /> cat /proc/cgroups | grep memory<br /> <br /> cd /sys/fs/cgroup/memory<br /> echo 1 &gt; memory.move_charge_at_immigrate<br /> <br /> for i in range{1..500}<br /> do<br /> mkdir kmem_test<br /> echo $$ &gt; kmem_test/cgroup.procs<br /> sleep 3600 &amp;<br /> echo $$ &gt; cgroup.procs<br /> echo `cat kmem_test/cgroup.procs` &gt; cgroup.procs<br /> rmdir kmem_test<br /> done<br /> <br /> cat /proc/cgroups | grep memory<br /> <br /> This patchset aims to make those kmem pages to drop the reference to<br /> memory cgroup by using the APIs of obj_cgroup. Finally, we can see that<br /> the number of the dying cgroups will not increase if we run the above test<br /> script.<br /> <br /> This patch (of 7):<br /> <br /> The rcu_read_lock/unlock only can guarantee that the memcg will not be<br /> freed, but it cannot guarantee the success of css_get (which is in the<br /> refill_stock when cached memcg changed) to memcg.<br /> <br /> rcu_read_lock()<br /> memcg = obj_cgroup_memcg(old)<br /> __memcg_kmem_uncharge(memcg)<br /> refill_stock(memcg)<br /> if (stock-&gt;cached != memcg)<br /> // css_get can change the ref counter from 0 back to 1.<br /> css_get(&amp;memcg-&gt;css)<br /> rcu_read_unlock()<br /> <br /> This fix is very like the commit:<br /> <br /> eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge")<br /> <br /> Fix this by holding a reference to the memcg which is passed to the<br /> __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix a use after free in siw_alloc_mr<br /> <br /> Our code analyzer reported a UAF.<br /> <br /> In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of<br /> siw_mr_add_mem(), mem is assigned to mr-&gt;mem and then mem is freed via<br /> kfree(mem) if xa_alloc_cyclic() failed. Here, mr-&gt;mem still point to a<br /> freed object. After, the execution continue up to the err_out branch of<br /> siw_alloc_mr, and the freed mr-&gt;mem is used in siw_mr_drop_mem(mr).<br /> <br /> My patch moves "mr-&gt;mem = mem" behind the if (xa_alloc_cyclic(..)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send<br /> <br /> In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).<br /> If some error happens in emac_tx_fill_tpd(), the skb will be freed via<br /> dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().<br /> But the freed skb is still used via skb-&gt;len by netdev_sent_queue(,skb-&gt;len).<br /> <br /> As i observed that emac_tx_fill_tpd() haven&amp;#39;t modified the value of skb-&gt;len,<br /> thus my patch assigns skb-&gt;len to &amp;#39;len&amp;#39; before the possible free and<br /> use &amp;#39;len&amp;#39; instead of skb-&gt;len later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: fix wild memory access when clearing fragments<br /> <br /> while testing re-assembly/re-fragmentation using act_ct, it&amp;#39;s possible to<br /> observe a crash like the following one:<br /> <br /> KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f]<br /> CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424<br /> Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017<br /> RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0<br /> Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48<br /> RSP: 0018:ffff888c31449db8 EFLAGS: 00010203<br /> RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960<br /> RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e<br /> RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350<br /> R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000<br /> R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160<br /> FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> inet_frag_destroy+0xa9/0x150<br /> call_timer_fn+0x2d/0x180<br /> run_timer_softirq+0x4fe/0xe70<br /> __do_softirq+0x197/0x5a0<br /> irq_exit_rcu+0x1de/0x200<br /> sysvec_apic_timer_interrupt+0x6b/0x80<br /> <br /> <br /> when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb<br /> results in putting random data in FRAG_CB(), and this causes those "wild"<br /> memory accesses later, when the rbtree is purged. Never overwrite the skb<br /> cb in case tcf_ct_handle_fragments() returns -EINPROGRESS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix RX consumer index logic in the error path.<br /> <br /> In bnxt_rx_pkt(), the RX buffers are expected to complete in order.<br /> If the RX consumer index indicates an out of order buffer completion,<br /> it means we are hitting a hardware bug and the driver will abort all<br /> remaining RX packets and reset the RX ring. The RX consumer index<br /> that we pass to bnxt_discard_rx() is not correct. We should be<br /> passing the current index (tmp_raw_cons) instead of the old index<br /> (raw_cons). This bug can cause us to be at the wrong index when<br /> trying to abort the next RX packet. It can crash like this:<br /> <br /> #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007<br /> #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232<br /> #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e<br /> #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978<br /> #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0<br /> #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e<br /> #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24<br /> #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e<br /> #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12<br /> #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5<br /> [exception RIP: bnxt_rx_pkt+237]<br /> RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213<br /> RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000<br /> RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000<br /> RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d<br /> R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0<br /> R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath10k: Fix a use after free in ath10k_htc_send_bundle<br /> <br /> In ath10k_htc_send_bundle, the bundle_skb could be freed by<br /> dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later<br /> by bundle_skb-&gt;len.<br /> <br /> As skb_len = bundle_skb-&gt;len, my patch replaces bundle_skb-&gt;len to<br /> skb_len after the bundle_skb was freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nftables: Fix a memleak from userdata error path in new objects<br /> <br /> Release object name if userdata allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: entry: always set GIC_PRIO_PSR_I_SET during entry<br /> <br /> Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1"<br /> on the command line hits a warning during kernel entry, due to the way<br /> we manipulate the PMR.<br /> <br /> Early in the entry sequence, we call lockdep_hardirqs_off() to inform<br /> lockdep that interrupts have been masked (as the HW sets DAIF wqhen<br /> entering an exception). Architecturally PMR_EL1 is not affected by<br /> exception entry, and we don&amp;#39;t set GIC_PRIO_PSR_I_SET in the PMR early in<br /> the exception entry sequence, so early in exception entry the PMR can<br /> indicate that interrupts are unmasked even though they are masked by<br /> DAIF.<br /> <br /> If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that<br /> interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the<br /> exception entry paths, and hence lockdep_hardirqs_off() will WARN() that<br /> something is amiss.<br /> <br /> We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during<br /> exception entry so that kernel code sees a consistent environment. We<br /> must also update local_daif_inherit() to undo this, as currently only<br /> touches DAIF. For other paths, local_daif_restore() will update both<br /> DAIF and the PMR. With this done, we can remove the existing special<br /> cases which set this later in the entry code.<br /> <br /> We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with<br /> local_daif_save(), as this will warn if it ever encounters<br /> (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This<br /> matches the gic_prio_kentry_setup that we have to retain for<br /> ret_to_user.<br /> <br /> The original splat from Zenghui&amp;#39;s report was:<br /> <br /> | DEBUG_LOCKS_WARN_ON(!irqs_disabled())<br /> | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8<br /> | Modules linked in:<br /> | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463<br /> | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)<br /> | pc : lockdep_hardirqs_off+0xd4/0xe8<br /> | lr : lockdep_hardirqs_off+0xd4/0xe8<br /> | sp : ffff80002a39bad0<br /> | pmr_save: 000000e0<br /> | x29: ffff80002a39bad0 x28: ffff0000de214bc0<br /> | x27: ffff0000de1c0400 x26: 000000000049b328<br /> | x25: 0000000000406f30 x24: ffff0000de1c00a0<br /> | x23: 0000000020400005 x22: ffff8000105f747c<br /> | x21: 0000000096000044 x20: 0000000000498ef9<br /> | x19: ffff80002a39bc88 x18: ffffffffffffffff<br /> | x17: 0000000000000000 x16: ffff800011c61eb0<br /> | x15: ffff800011700a88 x14: 0720072007200720<br /> | x13: 0720072007200720 x12: 0720072007200720<br /> | x11: 0720072007200720 x10: 0720072007200720<br /> | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0<br /> | x7 : ffff8000119f0800 x6 : c0000000ffff7fff<br /> | x5 : ffff8000119f07a8 x4 : 0000000000000001<br /> | x3 : 9bcdab23f2432800 x2 : ffff800011730538<br /> | x1 : 9bcdab23f2432800 x0 : 0000000000000000<br /> | Call trace:<br /> | lockdep_hardirqs_off+0xd4/0xe8<br /> | enter_from_kernel_mode.isra.5+0x7c/0xa8<br /> | el1_abort+0x24/0x100<br /> | el1_sync_handler+0x80/0xd0<br /> | el1_sync+0x6c/0x100<br /> | __arch_clear_user+0xc/0x90<br /> | load_elf_binary+0x9fc/0x1450<br /> | bprm_execve+0x404/0x880<br /> | kernel_execve+0x180/0x188<br /> | call_usermodehelper_exec_async+0xdc/0x158<br /> | ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethernet:enic: Fix a use after free bug in enic_hard_start_xmit<br /> <br /> In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside<br /> enic_queue_wq_skb, if some error happens, the skb will be freed<br /> by dev_kfree_skb(skb). But the freed skb is still used in<br /> skb_tx_timestamp(skb).<br /> <br /> My patch makes enic_queue_wq_skb() return error and goto spin_unlock()<br /> incase of error. The solution is provided by Govind.<br /> See https://lkml.org/lkml/2021/4/30/961.