Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921s: fix a possible memory leak in mt7921_load_patch<br /> <br /> Always release fw data at the end of mt7921_load_patch routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: asix: add proper error handling of usb read errors<br /> <br /> Syzbot once again hit uninit value in asix driver. The problem still the<br /> same -- asix_read_cmd() reads less bytes, than was requested by caller.<br /> <br /> Since all read requests are performed via asix_read_cmd() let&amp;#39;s catch<br /> usb related error there and add __must_check notation to be sure all<br /> callers actually check return value.<br /> <br /> So, this patch adds sanity check inside asix_read_cmd(), that simply<br /> checks if bytes read are not less, than was requested and adds missing<br /> error handling of asix_read_cmd() all across the driver code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: avoid kernel warning when changing RX ring parameters<br /> <br /> Calling ethtool changing the RX ring parameters like this:<br /> <br /> $ ethtool -G eth0 rx 1024<br /> <br /> on igc triggers kernel warnings like this:<br /> <br /> [ 225.198467] ------------[ cut here ]------------<br /> [ 225.198473] Missing unregister, handled but fix driver<br /> [ 225.198485] WARNING: CPU: 7 PID: 959 at net/core/xdp.c:168<br /> xdp_rxq_info_reg+0x79/0xd0<br /> [...]<br /> [ 225.198601] Call Trace:<br /> [ 225.198604] <br /> [ 225.198609] igc_setup_rx_resources+0x3f/0xe0 [igc]<br /> [ 225.198617] igc_ethtool_set_ringparam+0x30e/0x450 [igc]<br /> [ 225.198626] ethnl_set_rings+0x18a/0x250<br /> [ 225.198631] genl_family_rcv_msg_doit+0xca/0x110<br /> [ 225.198637] genl_rcv_msg+0xce/0x1c0<br /> [ 225.198640] ? rings_prepare_data+0x60/0x60<br /> [ 225.198644] ? genl_get_cmd+0xd0/0xd0<br /> [ 225.198647] netlink_rcv_skb+0x4e/0xf0<br /> [ 225.198652] genl_rcv+0x24/0x40<br /> [ 225.198655] netlink_unicast+0x20e/0x330<br /> [ 225.198659] netlink_sendmsg+0x23f/0x480<br /> [ 225.198663] sock_sendmsg+0x5b/0x60<br /> [ 225.198667] __sys_sendto+0xf0/0x160<br /> [ 225.198671] ? handle_mm_fault+0xb2/0x280<br /> [ 225.198676] ? do_user_addr_fault+0x1eb/0x690<br /> [ 225.198680] __x64_sys_sendto+0x20/0x30<br /> [ 225.198683] do_syscall_64+0x38/0x90<br /> [ 225.198687] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 225.198693] RIP: 0033:0x7f7ae38ac3aa<br /> <br /> igc_ethtool_set_ringparam() copies the igc_ring structure but neglects to<br /> reset the xdp_rxq_info member before calling igc_setup_rx_resources().<br /> This in turn calls xdp_rxq_info_reg() with an already registered xdp_rxq_info.<br /> <br /> Make sure to unregister the xdp_rxq_info structure first in<br /> igc_setup_rx_resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a btf decl_tag bug when tagging a function<br /> <br /> syzbot reported a btf decl_tag bug with stack trace below:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline]<br /> RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910<br /> ...<br /> Call Trace:<br /> <br /> btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198<br /> btf_check_all_types kernel/bpf/btf.c:4239 [inline]<br /> btf_parse_type_sec kernel/bpf/btf.c:4280 [inline]<br /> btf_parse kernel/bpf/btf.c:4513 [inline]<br /> btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047<br /> bpf_btf_load kernel/bpf/syscall.c:4039 [inline]<br /> __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679<br /> __do_sys_bpf kernel/bpf/syscall.c:4738 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:4736 [inline]<br /> __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The kasan error is triggered with an illegal BTF like below:<br /> type 0: void<br /> type 1: int<br /> type 2: decl_tag to func type 3<br /> type 3: func to func_proto type 8<br /> The total number of types is 4 and the type 3 is illegal<br /> since its func_proto type is out of range.<br /> <br /> Currently, the target type of decl_tag can be struct/union, var or func.<br /> Both struct/union and var implemented their own &amp;#39;resolve&amp;#39; callback functions<br /> and hence handled properly in kernel.<br /> But func type doesn&amp;#39;t have &amp;#39;resolve&amp;#39; callback function. When<br /> btf_decl_tag_resolve() tries to check func type, it tries to get<br /> vlen of its func_proto type, which triggered the above kasan error.<br /> <br /> To fix the issue, btf_decl_tag_resolve() needs to do btf_func_check()<br /> before trying to accessing func_proto type.<br /> In the current implementation, func type is checked with<br /> btf_func_check() in the main checking function btf_check_all_types().<br /> To fix the above kasan issue, let us implement &amp;#39;resolve&amp;#39; callback<br /> func type properly. The &amp;#39;resolve&amp;#39; callback will be also called<br /> in btf_check_all_types() for func types.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: unregister virtual clocks when unregistering physical clock.<br /> <br /> When unregistering a physical clock which has some virtual clocks,<br /> unregister the virtual clocks with it.<br /> <br /> This fixes the following oops, which can be triggered by unloading<br /> a driver providing a PTP clock when it has enabled virtual clocks:<br /> <br /> BUG: unable to handle page fault for address: ffffffffc04fc4d8<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:ptp_vclock_read+0x31/0xb0<br /> Call Trace:<br /> timecounter_read+0xf/0x50<br /> ptp_vclock_refresh+0x2c/0x50<br /> ? ptp_clock_release+0x40/0x40<br /> ptp_aux_kworker+0x17/0x30<br /> kthread_worker_fn+0x9b/0x240<br /> ? kthread_should_park+0x30/0x30<br /> kthread+0xe2/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full<br /> <br /> If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()<br /> returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial<br /> memory has been alloced by sk_msg_alloc(), that is, msg_tx-&gt;sg.size is<br /> greater than osize after sk_msg_alloc(), memleak occurs. To fix we use<br /> sk_msg_trim() to release the allocated memory, then goto wait for memory.<br /> <br /> Other call paths of sk_msg_alloc() have the similar issue, such as<br /> tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),<br /> as Cong Wang suggested.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> __tcp_close+0x279/0x470<br /> tcp_close+0x1f/0x60<br /> inet_release+0x3f/0x80<br /> __sock_release+0x3d/0xb0<br /> sock_close+0x11/0x20<br /> __fput+0x92/0x250<br /> task_work_run+0x6a/0xa0<br /> do_exit+0x33b/0xb60<br /> do_group_exit+0x2f/0xa0<br /> get_signal+0xb6/0x950<br /> arch_do_signal_or_restart+0xac/0x2a0<br /> exit_to_user_mode_prepare+0xa9/0x200<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x46/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> <br /> WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> kthread+0xe6/0x110<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: pgalloc: fix memory leak caused by pgd_free()<br /> <br /> pgd page is freed by generic implementation pgd_free() since commit<br /> f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"),<br /> however, there are scenarios that the system uses more than one page as<br /> the pgd table, in such cases the generic implementation pgd_free() won&amp;#39;t<br /> be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and<br /> MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER"<br /> will be set as "1", which will cause allocating two pages as the pgd<br /> table. Well, at the same time, the generic implementation pgd_free()<br /> just free one pgd page, which will result in the memory leak.<br /> <br /> The memory leak can be easily detected by executing shell command:<br /> "while true; do ls &gt; /dev/null; grep MemFree /proc/meminfo; done"

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: cdmm: Fix refcount leak in mips_cdmm_phys_base<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, We should use of_node_put() on it when done<br /> Add the missing of_node_put() to release the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init<br /> <br /> The reference counting issue happens in several error handling paths<br /> on a refcounted object "nc-&gt;dmac". In these paths, the function simply<br /> returns the error code, forgetting to balance the reference count of<br /> "nc-&gt;dmac", increased earlier by dma_request_channel(), which may<br /> cause refcount leaks.<br /> <br /> Fix it by decrementing the refcount of specific object in those error<br /> paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath10k: Fix error handling in ath10k_setup_msa_resources<br /> <br /> The device_node pointer is returned by of_parse_phandle() with refcount<br /> incremented. We should use of_node_put() on it when done.<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Don&amp;#39;t use DSISR for SLB faults<br /> <br /> Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data<br /> is read or write.") we use page_fault_is_write(regs-&gt;dsisr) in<br /> __bad_page_fault() to determine if the fault is for a read or write, and<br /> change the message printed accordingly.<br /> <br /> But SLB faults, aka Data Segment Interrupts, don&amp;#39;t set DSISR (Data<br /> Storage Interrupt Status Register) to a useful value. All ISA versions<br /> from v2.03 through v3.1 specify that the Data Segment Interrupt sets<br /> DSISR "to an undefined value". As far as I can see there&amp;#39;s no mention of<br /> SLB faults setting DSISR in any BookIV content either.<br /> <br /> This manifests as accesses that should be a read being incorrectly<br /> reported as writes, for example, using the xmon "dump" command:<br /> <br /> 0:mon&gt; d 0x5deadbeef0000000<br /> 5deadbeef0000000<br /> [359526.415354][ C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000<br /> [359526.415611][ C6] Faulting instruction address: 0xc00000000010a300<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400]<br /> pc: c00000000010a300: mread+0x90/0x190<br /> <br /> If we disassemble the PC, we see a load instruction:<br /> <br /> 0:mon&gt; di c00000000010a300<br /> c00000000010a300 89490000 lbz r10,0(r9)<br /> <br /> We can also see in exceptions-64s.S that the data_access_slb block<br /> doesn&amp;#39;t set IDSISR=1, which means it doesn&amp;#39;t load DSISR into pt_regs. So<br /> the value we&amp;#39;re using to determine if the fault is a read/write is some<br /> stale value in pt_regs from a previous page fault.<br /> <br /> Rework the printing logic to separate the SLB fault case out, and only<br /> print read/write in the cases where we can determine it.<br /> <br /> The result looks like eg:<br /> <br /> 0:mon&gt; d 0x5deadbeef0000000<br /> 5deadbeef0000000<br /> [ 721.779525][ C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000<br /> [ 721.779697][ C6] Faulting instruction address: 0xc00000000014cbe0<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]<br /> <br /> 0:mon&gt; d 0<br /> 0000000000000000<br /> [ 742.793242][ C6] BUG: Kernel NULL pointer dereference at 0x00000000<br /> [ 742.793316][ C6] Faulting instruction address: 0xc00000000014cbe0<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix race at socket teardown<br /> <br /> Fix a race in the xsk socket teardown code that can lead to a NULL pointer<br /> dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by<br /> setting xs-&gt;state to XSK_UNBOUND, sets xs-&gt;dev to NULL and then waits for any<br /> NAPI processing to terminate using synchronize_net(). After that, the release<br /> code starts to tear down the socket state and free allocated memory.<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> PGD 8000000932469067 P4D 8000000932469067 PUD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2<br /> Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015<br /> RIP: 0010:__xsk_sendmsg+0x2c/0x690<br /> [...]<br /> RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258<br /> RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800<br /> RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800<br /> R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000<br /> FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? aa_sk_perm+0x43/0x1b0<br /> xsk_sendmsg+0xf0/0x110<br /> sock_sendmsg+0x65/0x70<br /> __sys_sendto+0x113/0x190<br /> ? debug_smp_processor_id+0x17/0x20<br /> ? fpregs_assert_state_consistent+0x23/0x50<br /> ? exit_to_user_mode_prepare+0xa5/0x1d0<br /> __x64_sys_sendto+0x29/0x30<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> There are two problems with the current code. First, setting xs-&gt;dev to NULL<br /> before waiting for all users to stop using the socket is not correct. The<br /> entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()<br /> are all guarded by a test that xs-&gt;state is in the state XSK_BOUND and if not,<br /> it returns right away. But one process might have passed this test but still<br /> have not gotten to the point in which it uses xs-&gt;dev in the code. In this<br /> interim, a second process executing xsk_unbind_dev() might have set xs-&gt;dev to<br /> NULL which will lead to a crash for the first process. The solution here is<br /> just to get rid of this NULL assignment since it is not used anymore. Before<br /> commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),<br /> xs-&gt;dev was the gatekeeper to admit processes into the data plane functions,<br /> but it was replaced with the state variable xs-&gt;state in the aforementioned<br /> commit.<br /> <br /> The second problem is that synchronize_net() does not wait for any process in<br /> xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the<br /> state they rely on might be cleaned up prematurely. This can happen when the<br /> notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().<br /> Solve this by extending the RCU critical region from just the ndo_xsk_wakeup<br /> to the whole functions mentioned above, so that both the test of xs-&gt;state ==<br /> XSK_BOUND and the last use of any member of xs is covered by the RCU critical<br /> section. This will guarantee that when synchronize_net() completes, there will<br /> be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and<br /> state can be cleaned up safely. Note that we need to drop the RCU lock for the<br /> skb xmit path as it uses functions that might sleep. Due to this, we have to<br /> retest the xs-&gt;state after we grab the mutex that protects the skb xmit code<br /> from, among a number of things, an xsk_unbind_dev() being executed from the<br /> notifier at the same time.