Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: q6afe-clocks: fix reprobing of the driver<br /> <br /> Q6afe-clocks driver can get reprobed. For example if the APR services<br /> are restarted after the firmware crash. However currently Q6afe-clocks<br /> driver will oops because hw.init will get cleared during first _probe<br /> call. Rewrite the driver to fill the clock data at runtime rather than<br /> using big static array of clocks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: do asoc update earlier in sctp_sf_do_dupcook_a<br /> <br /> There&amp;#39;s a panic that occurs in a few of envs, the call trace is as below:<br /> <br /> [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI<br /> [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]<br /> [] sctp_assoc_control_transport+0x1b9/0x210 [sctp]<br /> [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]<br /> [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]<br /> [] sctp_do_sm+0xc3/0x2a0 [sctp]<br /> [] sctp_generate_timeout_event+0x81/0xf0 [sctp]<br /> <br /> This is caused by a transport use-after-free issue. When processing a<br /> duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK<br /> and SHUTDOWN chunks are allocated with the transort from the new asoc.<br /> However, later in the sideeffect machine, the old asoc is used to send<br /> them out and old asoc&amp;#39;s shutdown_last_sent_to is set to the transport<br /> that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually<br /> belongs to the new asoc. After the new_asoc is freed and the old asoc<br /> T2 timeout, the old asoc&amp;#39;s shutdown_last_sent_to that is already freed<br /> would be accessed in sctp_sf_t2_timer_expire().<br /> <br /> Thanks Alexander and Jere for helping dig into this issue.<br /> <br /> To fix it, this patch is to do the asoc update first, then allocate<br /> the COOKIE-ACK and SHUTDOWN chunks with the &amp;#39;updated&amp;#39; old asoc. This<br /> would make more sense, as a chunk from an asoc shouldn&amp;#39;t be sent out<br /> with another asoc. We had fixed quite a few issues caused by this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix inode leak on getattr error in __fh_to_dentry

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xprtrdma: Fix cwnd update ordering<br /> <br /> After a reconnect, the reply handler is opening the cwnd (and thus<br /> enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs()<br /> can post enough Receive WRs to receive their replies. This causes an<br /> RNR and the new connection is lost immediately.<br /> <br /> The race is most clearly exposed when KASAN and disconnect injection<br /> are enabled. This slows down rpcrdma_rep_create() enough to allow<br /> the send side to post a bunch of RPC Calls before the Receive<br /> completion handler can invoke ib_post_recv().

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