Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix null pointer dereference in svc_rqst_free()<br /> <br /> When alloc_pages_node() returns null in svc_rqst_alloc(), the<br /> null rq_scratch_page pointer will be dereferenced when calling<br /> put_page() in svc_rqst_free(). Fix it by adding a null check.<br /> <br /> Addresses-Coverity: ("Dereference after null check")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix potential null dereference on pointer status<br /> <br /> There are calls to idxd_cmd_exec that pass a null status pointer however<br /> a recent commit has added an assignment to *status that can end up<br /> with a null pointer dereference. The function expects a null status<br /> pointer sometimes as there is a later assignment to *status where<br /> status is first null checked. Fix the issue by null checking status<br /> before making the assignment.<br /> <br /> Addresses-Coverity: ("Explicit null dereferenced")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid touching checkpointed data in get_victim()<br /> <br /> In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR<br /> mode to select victim:<br /> <br /> 1. LFS is set to find source section during GC, the victim should have<br /> no checkpointed data, since after GC, section could not be set free for<br /> reuse.<br /> <br /> Previously, we only check valid chpt blocks in current segment rather<br /> than section, fix it.<br /> <br /> 2. SSR | AT_SSR are set to find target segment for writes which can be<br /> fully filled by checkpointed and newly written blocks, we should never<br /> select such segment, otherwise it can cause panic or data corruption<br /> during allocation, potential case is described as below:<br /> <br /> a) target segment has &amp;#39;n&amp;#39; (n

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Fix NULL pointer dereference for -&gt;get_features()<br /> <br /> get_features ops of pci_epc_ops may return NULL, causing NULL pointer<br /> dereference in pci_epf_test_alloc_space function. Let us add a check for<br /> pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid<br /> any such NULL pointer dereference and return -ENOTSUPP in case<br /> pci_epc_feature is not found.<br /> <br /> When the patch is not applied and EPC features is not implemented in the<br /> platform driver, we see the following dump due to kernel NULL pointer<br /> dereference.<br /> <br /> Call trace:<br /> pci_epf_test_bind+0xf4/0x388<br /> pci_epf_bind+0x3c/0x80<br /> pci_epc_epf_link+0xa8/0xcc<br /> configfs_symlink+0x1a4/0x48c<br /> vfs_symlink+0x104/0x184<br /> do_symlinkat+0x80/0xd4<br /> __arm64_sys_symlinkat+0x1c/0x24<br /> el0_svc_common.constprop.3+0xb8/0x170<br /> el0_svc_handler+0x70/0x88<br /> el0_svc+0x8/0x640<br /> Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400)<br /> ---[ end trace a438e3c5a24f9df0 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9064/1: hw_breakpoint: Do not directly check the event&amp;#39;s overflow_handler hook<br /> <br /> The commit 1879445dfa7b ("perf/core: Set event&amp;#39;s default<br /> ::overflow_handler()") set a default event-&gt;overflow_handler in<br /> perf_event_alloc(), and replace the check event-&gt;overflow_handler with<br /> is_default_overflow_handler(), but one is missing.<br /> <br /> Currently, the bp-&gt;overflow_handler can not be NULL. As a result,<br /> enable_single_step() is always not invoked.<br /> <br /> Comments from Zhen Lei:<br /> <br /> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix panic during f2fs_resize_fs()<br /> <br /> f2fs_resize_fs() hangs in below callstack with testcase:<br /> - mkfs 16GB image &amp; mount image<br /> - dd 8GB fileA<br /> - dd 8GB fileB<br /> - sync<br /> - rm fileA<br /> - sync<br /> - resize filesystem to 8GB<br /> <br /> kernel BUG at segment.c:2484!<br /> Call Trace:<br /> allocate_segment_by_default+0x92/0xf0 [f2fs]<br /> f2fs_allocate_data_block+0x44b/0x7e0 [f2fs]<br /> do_write_page+0x5a/0x110 [f2fs]<br /> f2fs_outplace_write_data+0x55/0x100 [f2fs]<br /> f2fs_do_write_data_page+0x392/0x850 [f2fs]<br /> move_data_page+0x233/0x320 [f2fs]<br /> do_garbage_collect+0x14d9/0x1660 [f2fs]<br /> free_segment_range+0x1f7/0x310 [f2fs]<br /> f2fs_resize_fs+0x118/0x330 [f2fs]<br /> __f2fs_ioctl+0x487/0x3680 [f2fs]<br /> __x64_sys_ioctl+0x8e/0xd0<br /> do_syscall_64+0x33/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> The root cause is we forgot to check that whether we have enough space<br /> in resized filesystem to store all valid blocks in before-resizing<br /> filesystem, then allocator will run out-of-space during block migration<br /> in free_segment_range().

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.