Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: Fix uninit buffer allocated by __getname()<br /> <br /> Fix uninit errors caused after buffer allocation given to &amp;#39;de&amp;#39;; by<br /> initializing the buffer with zeroes. The fix was found by using KMSAN.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: fix uninit memory after failed mi_read in mi_format_new<br /> <br /> Fix a KMSAN un-init bug found by syzkaller.<br /> <br /> ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be<br /> uptodate. We do not bring the buffer uptodate before setting it as<br /> uptodate. If the buffer were to not be uptodate, it could mean adding a<br /> buffer with un-init data to the mi record. Attempting to load that record<br /> will trigger KMSAN.<br /> <br /> Avoid this by setting the buffer as uptodate, if it’s not already, by<br /> overwriting it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix MSDU buffer types handling in RX error path<br /> <br /> Currently, packets received on the REO exception ring from<br /> unassociated peers are of MSDU buffer type, while the driver expects<br /> link descriptor type packets. These packets are not parsed further due<br /> to a return check on packet type in ath12k_hal_desc_reo_parse_err(),<br /> but the associated skb is not freed. This may lead to kernel<br /> crashes and buffer leaks.<br /> <br /> Hence to fix, update the RX error handler to explicitly drop<br /> MSDU buffer type packets received on the REO exception ring.<br /> This prevents further processing of invalid packets and ensures<br /> stability in the RX error handling path.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()<br /> <br /> Don&amp;#39;t add BO to the vdev-&gt;bo_list in ivpu_gem_create_object().<br /> When failure happens inside drm_gem_shmem_create(), the BO is not<br /> fully created and ivpu_gem_bo_free() callback will not be called<br /> causing a deleted BO to be left on the list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix an integer overflow in aie2_query_ctx_status_array()<br /> <br /> The unpublished smatch static checker reported a warning.<br /> <br /> drivers/accel/amdxdna/aie2_pci.c:904 aie2_query_ctx_status_array()<br /> warn: potential user controlled sizeof overflow<br /> &amp;#39;args-&gt;num_element * args-&gt;element_size&amp;#39; &amp;#39;1-u32max(user) * 1-u32max(user)&amp;#39;<br /> <br /> Even this will not cause a real issue, it is better to put a reasonable<br /> limitation for element_size and num_element. Add condition to make sure<br /> the input element_size

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpu: host1x: Fix race in syncpt alloc/free<br /> <br /> Fix race condition between host1x_syncpt_alloc()<br /> and host1x_syncpt_put() by using kref_put_mutex()<br /> instead of kref_put() + manual mutex locking.<br /> <br /> This ensures no thread can acquire the<br /> syncpt_mutex after the refcount drops to zero<br /> but before syncpt_release acquires it.<br /> This prevents races where syncpoints could<br /> be allocated while still being cleaned up<br /> from a previous release.<br /> <br /> Remove explicit mutex locking in syncpt_release<br /> as kref_put_mutex() handles this atomically.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smack: fix bug: unprivileged task can create labels<br /> <br /> If an unprivileged task is allowed to relabel itself<br /> (/smack/relabel-self is not empty),<br /> it can freely create new labels by writing their<br /> names into own /proc/PID/attr/smack/current<br /> <br /> This occurs because do_setattr() imports<br /> the provided label in advance,<br /> before checking "relabel-self" list.<br /> <br /> This change ensures that the "relabel-self" list<br /> is checked before importing the label.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()<br /> <br /> In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when<br /> setup_instance() fails with an error code. Fix that by freeing the urb<br /> before freeing the hw structure. Also change the error paths to use the<br /> goto ladder style.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Do not let BPF test infra emit invalid GSO types to stack<br /> <br /> Yinhao et al. reported that their fuzzer tool was able to trigger a<br /> skb_warn_bad_offload() from netif_skb_features() -&gt; gso_features_check().<br /> When a BPF program - triggered via BPF test infra - pushes the packet<br /> to the loopback device via bpf_clone_redirect() then mentioned offload<br /> warning can be seen. GSO-related features are then rightfully disabled.<br /> <br /> We get into this situation due to convert___skb_to_skb() setting<br /> gso_segs and gso_size but not gso_type. Technically, it makes sense<br /> that this warning triggers since the GSO properties are malformed due<br /> to the gso_type. Potentially, the gso_type could be marked non-trustworthy<br /> through setting it at least to SKB_GSO_DODGY without any other specific<br /> assumptions, but that also feels wrong given we should not go further<br /> into the GSO engine in the first place.<br /> <br /> The checks were added in 121d57af308d ("gso: validate gso_type in GSO<br /> handlers") because there were malicious (syzbot) senders that combine<br /> a protocol with a non-matching gso_type. If we would want to drop such<br /> packets, gso_features_check() currently only returns feature flags via<br /> netif_skb_features(), so one location for potentially dropping such skbs<br /> could be validate_xmit_unreadable_skb(), but then otoh it would be<br /> an additional check in the fast-path for a very corner case. Given<br /> bpf_clone_redirect() is the only place where BPF test infra could emit<br /> such packets, lets reject them right there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86: Fix NULL event access and potential PEBS record loss<br /> <br /> When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the<br /> perf_event_overflow() could be called to process the last PEBS record.<br /> <br /> While perf_event_overflow() could trigger the interrupt throttle and<br /> stop all events of the group, like what the below call-chain shows.<br /> <br /> perf_event_overflow()<br /> -&gt; __perf_event_overflow()<br /> -&gt;__perf_event_account_interrupt()<br /> -&gt; perf_event_throttle_group()<br /> -&gt; perf_event_throttle()<br /> -&gt; event-&gt;pmu-&gt;stop()<br /> -&gt; x86_pmu_stop()<br /> <br /> The side effect of stopping the events is that all corresponding event<br /> pointers in cpuc-&gt;events[] array are cleared to NULL.<br /> <br /> Assume there are two PEBS events (event a and event b) in a group. When<br /> intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the<br /> last PEBS record of PEBS event a, interrupt throttle is triggered and<br /> all pointers of event a and event b are cleared to NULL. Then<br /> intel_pmu_drain_pebs_icl() tries to process the last PEBS record of<br /> event b and encounters NULL pointer access.<br /> <br /> To avoid this issue, move cpuc-&gt;events[] clearing from x86_pmu_stop()<br /> to x86_pmu_del(). It&amp;#39;s safe since cpuc-&gt;active_mask or<br /> cpuc-&gt;pebs_enabled is always checked before access the event pointer<br /> from cpuc-&gt;events[].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: ETR: Fix ETR buffer use-after-free issue<br /> <br /> When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed<br /> and enabled again, currently sysfs_buf will point to the newly<br /> allocated memory(buf_new) and free the old memory(buf_old). But the<br /> etr_buf that is being used by the ETR remains pointed to buf_old, not<br /> updated to buf_new. In this case, it will result in a memory<br /> use-after-free issue.<br /> <br /> Fix this by checking ETR&amp;#39;s mode before updating and releasing buf_old,<br /> if the mode is CS_MODE_SYSFS, then skip updating and releasing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ns: initialize ns_list_node for initial namespaces<br /> <br /> Make sure that the list is always initialized for initial namespaces.