Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS<br /> <br /> UBSAN complains about array-index-out-of-bounds:<br /> [ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41<br /> [ 1.980709] kernel: index 15 is out of range for type &amp;#39;ahci_em_priv [8]&amp;#39;<br /> [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu<br /> [ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010<br /> [ 1.980718] kernel: Call Trace:<br /> [ 1.980721] kernel: <br /> [ 1.980723] kernel: show_stack+0x52/0x58<br /> [ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f<br /> [ 1.980734] kernel: dump_stack+0x10/0x12<br /> [ 1.980736] kernel: ubsan_epilogue+0x9/0x45<br /> [ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49<br /> [ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci]<br /> [ 1.980748] kernel: ata_qc_issue+0x135/0x240<br /> [ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580<br /> [ 1.980754] kernel: ? vprintk_default+0x1d/0x20<br /> [ 1.980759] kernel: ata_exec_internal+0x67/0xa0<br /> [ 1.980762] kernel: sata_pmp_read+0x8d/0xc0<br /> [ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90<br /> [ 1.980768] kernel: sata_pmp_attach+0x8b/0x310<br /> [ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0<br /> [ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30<br /> [ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci]<br /> [ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci]<br /> [ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci]<br /> [ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0<br /> [ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560<br /> [ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40<br /> [ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci]<br /> [ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600<br /> [ 1.980810] kernel: ata_scsi_error+0x9c/0xd0<br /> [ 1.980813] kernel: scsi_error_handler+0xa1/0x180<br /> [ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0<br /> [ 1.980820] kernel: kthread+0x12a/0x150<br /> [ 1.980823] kernel: ? set_kthread_struct+0x50/0x50<br /> [ 1.980826] kernel: ret_from_fork+0x22/0x30<br /> [ 1.980831] kernel: <br /> <br /> This happens because sata_pmp_init_links() initialize link-&gt;pmp up to<br /> SATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.<br /> <br /> I can&amp;#39;t find the maximum Enclosure Management ports specified in AHCI<br /> spec v1.3.1, but "12.2.1 LED message type" states that "Port Multiplier<br /> Information" can utilize 4 bits, which implies it can support up to 16<br /> ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve the<br /> issue.<br /> <br /> BugLink: https://bugs.launchpad.net/bugs/1970074

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: Fix kmemleak in orangefs_sysfs_init()<br /> <br /> When insert and remove the orangefs module, there are kobjects memory<br /> leaked as below:<br /> <br /> unreferenced object 0xffff88810f95af00 (size 64):<br /> comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)<br /> hex dump (first 32 bytes):<br /> a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................<br /> 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] orangefs_sysfs_init+0x42/0x3a0<br /> [] 0xffffffffa02780fe<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x2f98/0x3330<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> unreferenced object 0xffff88810f95ae80 (size 64):<br /> comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)<br /> hex dump (first 32 bytes):<br /> c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................<br /> 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] orangefs_sysfs_init+0xc7/0x3a0<br /> [] 0xffffffffa02780fe<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x2f98/0x3330<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> unreferenced object 0xffff88810f95ae00 (size 64):<br /> comm "insmod", pid 783, jiffies 4294813440 (age 65.511s)<br /> hex dump (first 32 bytes):<br /> 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `...............<br /> 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] orangefs_sysfs_init+0x12b/0x3a0<br /> [] 0xffffffffa02780fe<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x2f98/0x3330<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> unreferenced object 0xffff88810f95ad80 (size 64):<br /> comm "insmod", pid 783, jiffies 4294813440 (age 65.511s)<br /> hex dump (first 32 bytes):<br /> 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x...............<br /> 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] orangefs_sysfs_init+0x1ac/0x3a0<br /> [] 0xffffffffa02780fe<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x2f98/0x3330<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> unreferenced object 0xffff88810f95ac00 (size 64):<br /> comm "insmod", pid 783, jiffies 4294813440 (age 65.531s)<br /> hex dump (first 32 bytes):<br /> e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g.............<br /> 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] orangefs_sysfs_init+0x291/0x3a0<br /> [] 0xffffffffa02780fe<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x2f98/0x3330<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: megachips: Fix a null pointer dereference bug<br /> <br /> When removing the module we will get the following warning:<br /> <br /> [ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered<br /> [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI<br /> [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130<br /> [ 31.921825] Call Trace:<br /> [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw]<br /> [ 31.923139] i2c_device_remove+0x181/0x1f0<br /> <br /> The two bridges (stdp2690, stdp4028) do not probe at the same time, so<br /> the driver does not call ge_b850v3_resgiter() when probing, causing the<br /> driver to try to remove the object that has not been initialized.<br /> <br /> Fix this by checking whether both the bridges are probed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox()<br /> <br /> pci_get_device() will increase the reference count for the returned<br /> &amp;#39;dev&amp;#39;. We need to call pci_dev_put() to decrease the reference count.<br /> Since &amp;#39;dev&amp;#39; is only used in pci_read_config_dword(), let&amp;#39;s add<br /> pci_dev_put() right after it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: trbe: remove cpuhp instance node before remove cpuhp state<br /> <br /> cpuhp_state_add_instance() and cpuhp_state_remove_instance() should<br /> be used in pairs. Or there will lead to the warn on<br /> cpuhp_remove_multi_state() since the cpuhp_step list is not empty.<br /> <br /> The following is the error log with &amp;#39;rmmod coresight-trbe&amp;#39;:<br /> Error: Removing state 215 which has instances left.<br /> Call trace:<br /> __cpuhp_remove_state_cpuslocked+0x144/0x160<br /> __cpuhp_remove_state+0xac/0x100<br /> arm_trbe_device_remove+0x2c/0x60 [coresight_trbe]<br /> platform_remove+0x34/0x70<br /> device_remove+0x54/0x90<br /> device_release_driver_internal+0x1e4/0x250<br /> driver_detach+0x5c/0xb0<br /> bus_remove_driver+0x64/0xc0<br /> driver_unregister+0x3c/0x70<br /> platform_driver_unregister+0x20/0x30<br /> arm_trbe_exit+0x1c/0x658 [coresight_trbe]<br /> __arm64_sys_delete_module+0x1ac/0x24c<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0x58/0x1a0<br /> do_el0_svc+0x38/0xd0<br /> el0_svc+0x2c/0xc0<br /> el0t_64_sync_handler+0x1ac/0x1b0<br /> el0t_64_sync+0x19c/0x1a0<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sof_es8336: fix possible use-after-free in sof_es8336_remove()<br /> <br /> sof_es8336_remove() calls cancel_delayed_work(). However, that<br /> function does not wait until the work function finishes. This<br /> means that the callback function may still be running after<br /> the driver&amp;#39;s remove function has finished, which would result<br /> in a use-after-free.<br /> <br /> Fix by calling cancel_delayed_work_sync(), which ensures that<br /> the work is properly cancelled, no longer running, and unable<br /> to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix potential out of bound read in ext4_fc_replay_scan()<br /> <br /> For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain<br /> space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read<br /> when mounting corrupt file system image.<br /> ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this<br /> three tags will read data during scan, tag length couldn&amp;#39;t less than data length<br /> which will read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: fix out-of-bounds access on cio_ignore free<br /> <br /> The channel-subsystem-driver scans for newly available devices whenever<br /> device-IDs are removed from the cio_ignore list using a command such as:<br /> <br /> echo free &gt;/proc/cio_ignore<br /> <br /> Since an I/O device scan might interfer with running I/Os, commit<br /> 172da89ed0ea ("s390/cio: avoid excessive path-verification requests")<br /> introduced an optimization to exclude online devices from the scan.<br /> <br /> The newly added check for online devices incorrectly assumes that<br /> an I/O-subchannel&amp;#39;s drvdata points to a struct io_subchannel_private.<br /> For devices that are bound to a non-default I/O subchannel driver, such<br /> as the vfio_ccw driver, this results in an out-of-bounds read access<br /> during each scan.<br /> <br /> Fix this by changing the scan logic to rely on a driver-independent<br /> online indication. For this we can use struct subchannel-&gt;config.ena,<br /> which is the driver&amp;#39;s requested subchannel-enabled state. Since I/Os<br /> can only be started on enabled subchannels, this matches the intent<br /> of the original optimization of not scanning devices where I/O might<br /> be running.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: Add checks for devm_kcalloc<br /> <br /> As the devm_kcalloc may return NULL, the return value needs to be checked<br /> to avoid NULL poineter dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6mr: fix UAF issue in ip6mr_sk_done() when addrconf_init_net() failed<br /> <br /> If the initialization fails in calling addrconf_init_net(), devconf_all is<br /> the pointer that has been released. Then ip6mr_sk_done() is called to<br /> release the net, accessing devconf-&gt;mc_forwarding directly causes invalid<br /> pointer access.<br /> <br /> The process is as follows:<br /> setup_net()<br /> ops_init()<br /> addrconf_init_net()<br /> all = kmemdup(...) ---&gt; alloc "all"<br /> ...<br /> net-&gt;ipv6.devconf_all = all;<br /> __addrconf_sysctl_register() ---&gt; failed<br /> ...<br /> kfree(all); ---&gt; ipv6.devconf_all invalid<br /> ...<br /> ops_exit_list()<br /> ...<br /> ip6mr_sk_done()<br /> devconf = net-&gt;ipv6.devconf_all;<br /> //devconf is invalid pointer<br /> if (!devconf || !atomic_read(&amp;devconf-&gt;mc_forwarding))<br /> <br /> The following is the Call Trace information:<br /> BUG: KASAN: use-after-free in ip6mr_sk_done+0x112/0x3a0<br /> Read of size 4 at addr ffff888075508e88 by task ip/14554<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8e/0xd1<br /> print_report+0x155/0x454<br /> kasan_report+0xba/0x1f0<br /> kasan_check_range+0x35/0x1b0<br /> ip6mr_sk_done+0x112/0x3a0<br /> rawv6_close+0x48/0x70<br /> inet_release+0x109/0x230<br /> inet6_release+0x4c/0x70<br /> sock_release+0x87/0x1b0<br /> igmp6_net_exit+0x6b/0x170<br /> ops_exit_list+0xb0/0x170<br /> setup_net+0x7ac/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f7963322547<br /> <br /> <br /> Allocated by task 14554:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0xa1/0xb0<br /> __kmalloc_node_track_caller+0x4a/0xb0<br /> kmemdup+0x28/0x60<br /> addrconf_init_net+0x1be/0x840<br /> ops_init+0xa5/0x410<br /> setup_net+0x5aa/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Freed by task 14554:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x155/0x1b0<br /> slab_free_freelist_hook+0x11b/0x220<br /> __kmem_cache_free+0xa4/0x360<br /> addrconf_init_net+0x623/0x840<br /> ops_init+0xa5/0x410<br /> setup_net+0x5aa/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: Fix refcount leak in cxl_calc_capp_routing<br /> <br /> of_get_next_parent() returns a node pointer with refcount incremented,<br /> we should use of_node_put() on it when not need anymore.<br /> This function only calls of_node_put() in normal path,<br /> missing it in the error path.<br /> Add missing of_node_put() to avoid refcount leak.