Vulnerabilities

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 /> dax: make sure inodes are flushed before destroy cache<br /> <br /> A bug can be triggered by following command<br /> <br /> $ modprobe nd_pmem &amp;&amp; modprobe -r nd_pmem<br /> <br /> [ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()<br /> [ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)<br /> [ 10.062433] Call Trace:<br /> [ 10.062673] dump_stack_lvl+0x34/0x44<br /> [ 10.062865] slab_err+0x90/0xd0<br /> [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0<br /> [ 10.063848] kmem_cache_destroy+0x4a/0x110<br /> [ 10.064058] __x64_sys_delete_module+0x265/0x300<br /> <br /> This is caused by dax_fs_exit() not flushing inodes before destroy cache.<br /> To fix this issue, call rcu_barrier() before destroy cache.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: populate connector of struct dp_panel<br /> <br /> DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose<br /> and expect DP source return correct checksum. During drm edid read,<br /> correct edid checksum is calculated and stored at<br /> connector::real_edid_checksum.<br /> <br /> The problem is struct dp_panel::connector never be assigned, instead the<br /> connector is stored in struct msm_dp::connector. When we run compliance<br /> testing test case 4.2.2.6 dp_panel_handle_sink_request() won&amp;#39;t have a valid<br /> edid set in struct dp_panel::edid so we&amp;#39;ll try to use the connectors<br /> real_edid_checksum and hit a NULL pointer dereference error because the<br /> connector pointer is never assigned.<br /> <br /> Changes in V2:<br /> -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps()<br /> <br /> Changes in V3:<br /> -- remove unhelpful kernel crash trace commit text<br /> -- remove renaming dp_display parameter to dp<br /> <br /> Changes in V4:<br /> -- add more details to commit text<br /> <br /> Changes in v10:<br /> -- group into one series<br /> <br /> Changes in v11:<br /> -- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read<br /> <br /> Signee-off-by: Kuogee Hsieh

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: anx7625: Fix overflow issue on reading EDID<br /> <br /> The length of EDID block can be longer than 256 bytes, so we should use<br /> `int` instead of `u8` for the `edid_pos` variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Hold port reference until decoder release<br /> <br /> KASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in<br /> cxl_decoder_release() where it goes to reference its parent, a cxl_port,<br /> to free its id back to port-&gt;decoder_ida.<br /> <br /> BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core]<br /> Read of size 8 at addr ffff888119270908 by task kworker/35:2/379<br /> <br /> CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Workqueue: events kobject_delayed_cleanup<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x59/0x73<br /> print_address_description.constprop.0+0x1f/0x150<br /> ? to_cxl_port+0x18/0x90 [cxl_core]<br /> kasan_report.cold+0x83/0xdf<br /> ? to_cxl_port+0x18/0x90 [cxl_core]<br /> to_cxl_port+0x18/0x90 [cxl_core]<br /> cxl_decoder_release+0x2a/0x60 [cxl_core]<br /> device_release+0x5f/0x100<br /> kobject_cleanup+0x80/0x1c0<br /> <br /> The device core only guarantees parent lifetime until all children are<br /> unregistered. If a child needs a parent to complete its -&gt;release()<br /> callback that child needs to hold a reference to extend the lifetime of<br /> the parent.

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.