Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()<br /> <br /> If device_register() fails in cxl_register_afu|adapter(), the device<br /> is not added, device_unregister() can not be called in the error path,<br /> otherwise it will cause a null-ptr-deref because of removing not added<br /> device.<br /> <br /> As comment of device_register() says, it should use put_device() to give<br /> up the reference in the error path. So split device_unregister() into<br /> device_del() and put_device(), then goes to put dev when register fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Clean up si_domain in the init_dmars() error path<br /> <br /> A splat from kmem_cache_destroy() was seen with a kernel prior to<br /> commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool")<br /> when there was a failure in init_dmars(), because the iommu_domain<br /> cache still had objects. While the mempool code is now gone, there<br /> still is a leak of the si_domain memory if init_dmars() fails. So<br /> clean up si_domain in the init_dmars() error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macintosh: fix possible memory leak in macio_add_one_device()<br /> <br /> Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device&amp;#39;s<br /> bus_id string array"), the name of device is allocated dynamically. It<br /> needs to be freed when of_device_register() fails. Call put_device() to<br /> give up the reference that&amp;#39;s taken in device_initialize(), so that it<br /> can be freed in kobject_cleanup() when the refcount hits 0.<br /> <br /> macio device is freed in macio_release_dev(), so the kfree() can be<br /> removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: Init completion before kobject_init_and_add()<br /> <br /> In cpufreq_policy_alloc(), it will call uninitialed completion in<br /> cpufreq_sysfs_release() when kobject_init_and_add() fails. And<br /> that will cause a crash such as the following page fault in complete:<br /> <br /> BUG: unable to handle page fault for address: fffffffffffffff8<br /> [..]<br /> RIP: 0010:complete+0x98/0x1f0<br /> [..]<br /> Call Trace:<br /> kobject_put+0x1be/0x4c0<br /> cpufreq_online.cold+0xee/0x1fd<br /> cpufreq_add_dev+0x183/0x1e0<br /> subsys_interface_register+0x3f5/0x4e0<br /> cpufreq_register_driver+0x3b7/0x670<br /> acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq]<br /> do_one_initcall+0x13d/0x780<br /> do_init_module+0x1c3/0x630<br /> load_module+0x6e67/0x73b0<br /> __do_sys_finit_module+0x181/0x240<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mad: Don&amp;#39;t call to function that might sleep while in atomic context<br /> <br /> Tracepoints are not allowed to sleep, as such the following splat is<br /> generated due to call to ib_query_pkey() in atomic context.<br /> <br /> WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220<br /> CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1<br /> Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014<br /> Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]<br /> RIP: 0010:rb_commit+0xc1/0x220<br /> RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202<br /> RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246<br /> RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246<br /> R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0<br /> Call Trace:<br /> ring_buffer_unlock_commit+0x1d/0xa0<br /> trace_buffer_unlock_commit_regs+0x3b/0x1b0<br /> trace_event_buffer_commit+0x67/0x1d0<br /> trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core]<br /> ib_mad_recv_done+0x48b/0xc10 [ib_core]<br /> ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]<br /> __ib_process_cq+0x91/0x1c0 [ib_core]<br /> ib_cq_poll_work+0x26/0x80 [ib_core]<br /> process_one_work+0x1a7/0x360<br /> ? create_worker+0x1a0/0x1a0<br /> worker_thread+0x30/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> kthread+0x116/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ret_from_fork+0x35/0x40<br /> ---[ end trace 78ba8509d3830a16 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/gntdev: Accommodate VMA splitting<br /> <br /> Prior to this commit, the gntdev driver code did not handle the<br /> following scenario correctly with paravirtualized (PV) Xen domains:<br /> <br /> * User process sets up a gntdev mapping composed of two grant mappings<br /> (i.e., two pages shared by another Xen domain).<br /> * User process munmap()s one of the pages.<br /> * User process munmap()s the remaining page.<br /> * User process exits.<br /> <br /> In the scenario above, the user process would cause the kernel to log<br /> the following messages in dmesg for the first munmap(), and the second<br /> munmap() call would result in similar log messages:<br /> <br /> BUG: Bad page map in process doublemap.test pte:... pmd:...<br /> page:0000000057c97bff refcount:1 mapcount:-1 \<br /> mapping:0000000000000000 index:0x0 pfn:...<br /> ...<br /> page dumped because: bad pte<br /> ...<br /> file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x46/0x5e<br /> print_bad_pte.cold+0x66/0xb6<br /> unmap_page_range+0x7e5/0xdc0<br /> unmap_vmas+0x78/0xf0<br /> unmap_region+0xa8/0x110<br /> __do_munmap+0x1ea/0x4e0<br /> __vm_munmap+0x75/0x120<br /> __x64_sys_munmap+0x28/0x40<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x61/0xcb<br /> ...<br /> <br /> For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG)<br /> would print out the following and trigger a general protection fault in<br /> the affected Xen PV domain:<br /> <br /> (XEN) d0v... Attempt to implicitly unmap d0&amp;#39;s grant PTE ...<br /> (XEN) d0v... Attempt to implicitly unmap d0&amp;#39;s grant PTE ...<br /> <br /> As of this writing, gntdev_grant_map structure&amp;#39;s vma field (referred to<br /> as map-&gt;vma below) is mainly used for checking the start and end<br /> addresses of mappings. However, with split VMAs, these may change, and<br /> there could be more than one VMA associated with a gntdev mapping.<br /> Hence, remove the use of map-&gt;vma and rely on map-&gt;pages_vm_start for<br /> the original start address and on (map-&gt;count live_grants atomic counter and/or the map-&gt;vma<br /> pointer (the latter of which is now removed). This prevents the<br /> userspace from mmap()&amp;#39;ing (with MAP_FIXED) a gntdev mapping over the<br /> same address range as a previously set up gntdev mapping. This scenario<br /> can be summarized with the following call-trace, which was valid prior<br /> to this commit:<br /> <br /> mmap<br /> gntdev_mmap<br /> mmap (repeat mmap with MAP_FIXED over the same address range)<br /> gntdev_invalidate<br /> unmap_grant_pages (sets &amp;#39;being_removed&amp;#39; entries to true)<br /> gnttab_unmap_refs_async<br /> unmap_single_vma<br /> gntdev_mmap (maps the shared pages again)<br /> munmap<br /> gntdev_invalidate<br /> unmap_grant_pages<br /> (no-op because &amp;#39;being_removed&amp;#39; entries are true)<br /> unmap_single_vma (For PV domains, Xen reports that a granted page<br /> is being unmapped and triggers a general protection fault in the<br /> affected domain, if Xen was built with CONFIG_DEBUG)<br /> <br /> The fix for this last scenario could be worth its own commit, but we<br /> opted for a single commit, because removing the gntdev_grant_map<br /> structure&amp;#39;s vma field requires guarding the entry to gntdev_mmap(), and<br /> the live_grants atomic counter is not sufficient on its own to prevent<br /> the mmap() over a pre-existing mapping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Remove device endpoints from bandwidth list when freeing the device<br /> <br /> Endpoints are normally deleted from the bandwidth list when they are<br /> dropped, before the virt device is freed.<br /> <br /> If xHC host is dying or being removed then the endpoints aren&amp;#39;t dropped<br /> cleanly due to functions returning early to avoid interacting with a<br /> non-accessible host controller.<br /> <br /> So check and delete endpoints that are still on the bandwidth list when<br /> freeing the virt device.<br /> <br /> Solves a list_del corruption kernel crash when unbinding xhci-pci,<br /> caused by xhci_mem_cleanup() when it later tried to delete already freed<br /> endpoints from the bandwidth list.<br /> <br /> This only affects hosts that use software bandwidth checking, which<br /> currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup: split cgroup_destroy_wq into 3 workqueues<br /> <br /> A hung task can occur during [1] LTP cgroup testing when repeatedly<br /> mounting/unmounting perf_event and net_prio controllers with<br /> systemd.unified_cgroup_hierarchy=1. The hang manifests in<br /> cgroup_lock_and_drain_offline() during root destruction.<br /> <br /> Related case:<br /> cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event<br /> cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio<br /> <br /> Call Trace:<br /> cgroup_lock_and_drain_offline+0x14c/0x1e8<br /> cgroup_destroy_root+0x3c/0x2c0<br /> css_free_rwork_fn+0x248/0x338<br /> process_one_work+0x16c/0x3b8<br /> worker_thread+0x22c/0x3b0<br /> kthread+0xec/0x100<br /> ret_from_fork+0x10/0x20<br /> <br /> Root Cause:<br /> <br /> CPU0 CPU1<br /> mount perf_event umount net_prio<br /> cgroup1_get_tree cgroup_kill_sb<br /> rebind_subsystems // root destruction enqueues<br /> // cgroup_destroy_wq<br /> // kill all perf_event css<br /> // one perf_event css A is dying<br /> // css A offline enqueues cgroup_destroy_wq<br /> // root destruction will be executed first<br /> css_free_rwork_fn<br /> cgroup_destroy_root<br /> cgroup_lock_and_drain_offline<br /> // some perf descendants are dying<br /> // cgroup_destroy_wq max_active = 1<br /> // waiting for css A to die<br /> <br /> Problem scenario:<br /> 1. CPU0 mounts perf_event (rebind_subsystems)<br /> 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work<br /> 3. A dying perf_event CSS gets queued for offline after root destruction<br /> 4. Root destruction waits for offline completion, but offline work is<br /> blocked behind root destruction in cgroup_destroy_wq (max_active=1)<br /> <br /> Solution:<br /> Split cgroup_destroy_wq into three dedicated workqueues:<br /> cgroup_offline_wq – Handles CSS offline operations<br /> cgroup_release_wq – Manages resource release<br /> cgroup_free_wq – Performs final memory deallocation<br /> <br /> This separation eliminates blocking in the CSS free path while waiting for<br /> offline operations to complete.<br /> <br /> [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: avoid buffer overflow in WID string configuration<br /> <br /> Fix the following copy overflow warning identified by Smatch checker.<br /> <br /> drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()<br /> error: &amp;#39;__memcpy()&amp;#39; &amp;#39;cfg-&gt;s[i]-&gt;str&amp;#39; copy overflow (512 vs 65537)<br /> <br /> This patch introduces size check before accessing the memory buffer.<br /> The checks are base on the WID type of received data from the firmware.<br /> For WID string configuration, the size limit is determined by individual<br /> element size in &amp;#39;struct wilc_cfg_str_vals&amp;#39; that is maintained in &amp;#39;len&amp;#39; field<br /> of &amp;#39;struct wilc_cfg_str&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: virtio_uml: Fix use-after-free after put_device in probe<br /> <br /> When register_virtio_device() fails in virtio_uml_probe(),<br /> the code sets vu_dev-&gt;registered = 1 even though<br /> the device was not successfully registered.<br /> This can lead to use-after-free or other issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR<br /> <br /> A NULL pointer dereference can occur in tcp_ao_finish_connect() during a<br /> connect() system call on a socket with a TCP-AO key added and TCP_REPAIR<br /> enabled.<br /> <br /> The function is called with skb being NULL and attempts to dereference it<br /> on tcp_hdr(skb)-&gt;seq without a prior skb validation.<br /> <br /> Fix this by checking if skb is NULL before dereferencing it.<br /> <br /> The commentary is taken from bpf_skops_established(), which is also called<br /> in the same flow. Unlike the function being patched,<br /> bpf_skops_established() validates the skb before dereferencing it.<br /> <br /> int main(void){<br /> struct sockaddr_in sockaddr;<br /> struct tcp_ao_add tcp_ao;<br /> int sk;<br /> int one = 1;<br /> <br /> memset(&amp;sockaddr,&amp;#39;\0&amp;#39;,sizeof(sockaddr));<br /> memset(&amp;tcp_ao,&amp;#39;\0&amp;#39;,sizeof(tcp_ao));<br /> <br /> sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);<br /> <br /> sockaddr.sin_family = AF_INET;<br /> <br /> memcpy(tcp_ao.alg_name,"cmac(aes128)",12);<br /> memcpy(tcp_ao.key,"ABCDEFGHABCDEFGH",16);<br /> tcp_ao.keylen = 16;<br /> <br /> memcpy(&amp;tcp_ao.addr,&amp;sockaddr,sizeof(sockaddr));<br /> <br /> setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &amp;tcp_ao,<br /> sizeof(tcp_ao));<br /> setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &amp;one, sizeof(one));<br /> <br /> sockaddr.sin_family = AF_INET;<br /> sockaddr.sin_port = htobe16(123);<br /> <br /> inet_aton("127.0.0.1", &amp;sockaddr.sin_addr);<br /> <br /> connect(sk,(struct sockaddr *)&amp;sockaddr,sizeof(sockaddr));<br /> <br /> return 0;<br /> }<br /> <br /> $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall<br /> $ unshare -Urn<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000b6<br /> PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop<br /> Reference Platform, BIOS 6.00 11/12/2020<br /> RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qed: Don&amp;#39;t collect too many protection override GRC elements<br /> <br /> In the protection override dump path, the firmware can return far too<br /> many GRC elements, resulting in attempting to write past the end of the<br /> previously-kmalloc&amp;#39;ed dump buffer.<br /> <br /> This will result in a kernel panic with reason:<br /> <br /> BUG: unable to handle kernel paging request at ADDRESS<br /> <br /> where "ADDRESS" is just past the end of the protection override dump<br /> buffer. The start address of the buffer is:<br /> p_hwfn-&gt;cdev-&gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf<br /> and the size of the buffer is buf_size in the same data structure.<br /> <br /> The panic can be arrived at from either the qede Ethernet driver path:<br /> <br /> [exception RIP: qed_grc_dump_addr_range+0x108]<br /> qed_protection_override_dump at ffffffffc02662ed [qed]<br /> qed_dbg_protection_override_dump at ffffffffc0267792 [qed]<br /> qed_dbg_feature at ffffffffc026aa8f [qed]<br /> qed_dbg_all_data at ffffffffc026b211 [qed]<br /> qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]<br /> devlink_health_do_dump at ffffffff82497f61<br /> devlink_health_report at ffffffff8249cf29<br /> qed_report_fatal_error at ffffffffc0272baf [qed]<br /> qede_sp_task at ffffffffc045ed32 [qede]<br /> process_one_work at ffffffff81d19783<br /> <br /> or the qedf storage driver path:<br /> <br /> [exception RIP: qed_grc_dump_addr_range+0x108]<br /> qed_protection_override_dump at ffffffffc068b2ed [qed]<br /> qed_dbg_protection_override_dump at ffffffffc068c792 [qed]<br /> qed_dbg_feature at ffffffffc068fa8f [qed]<br /> qed_dbg_all_data at ffffffffc0690211 [qed]<br /> qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]<br /> devlink_health_do_dump at ffffffff8aa95e51<br /> devlink_health_report at ffffffff8aa9ae19<br /> qed_report_fatal_error at ffffffffc0697baf [qed]<br /> qed_hw_err_notify at ffffffffc06d32d7 [qed]<br /> qed_spq_post at ffffffffc06b1011 [qed]<br /> qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]<br /> qedf_cleanup_fcport at ffffffffc05e7597 [qedf]<br /> qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]<br /> fc_rport_work at ffffffffc02da715 [libfc]<br /> process_one_work at ffffffff8a319663<br /> <br /> Resolve this by clamping the firmware&amp;#39;s return value to the maximum<br /> number of legal elements the firmware should return.