Vulnerabilities

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 /> 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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stackmap overflow check in __bpf_get_stackid()<br /> <br /> Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()<br /> when copying stack trace data. The issue occurs when the perf trace<br /> contains more stack entries than the stack map bucket can hold,<br /> leading to an out-of-bounds write in the bucket&amp;#39;s data array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: aead - Fix reqsize handling<br /> <br /> Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")<br /> introduced cra_reqsize field in crypto_alg struct to replace type<br /> specific reqsize fields. It looks like this was introduced specifically<br /> for ahash and acomp from the commit description as subsequent commits<br /> add necessary changes in these alg frameworks.<br /> <br /> However, this is being recommended for use in all crypto algs<br /> instead of setting reqsize using crypto_*_set_reqsize(). Using<br /> cra_reqsize in aead algorithms, hence, causes memory corruptions and<br /> crashes as the underlying functions in the algorithm framework have not<br /> been updated to set the reqsize properly from cra_reqsize. [1]<br /> <br /> Add proper set_reqsize calls in the aead init function to properly<br /> initialize reqsize for these algorithms in the framework.<br /> <br /> [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix null deref on srq-&gt;rq.queue after resize failure<br /> <br /> A NULL pointer dereference can occur in rxe_srq_chk_attr() when<br /> ibv_modify_srq() is invoked twice in succession under certain error<br /> conditions. The first call may fail in rxe_queue_resize(), which leads<br /> rxe_srq_from_attr() to set srq-&gt;rq.queue = NULL. The second call then<br /> triggers a crash (null deref) when accessing<br /> srq-&gt;rq.queue-&gt;buf-&gt;index_mask.<br /> <br /> Call Trace:<br /> <br /> rxe_modify_srq+0x170/0x480 [rdma_rxe]<br /> ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]<br /> ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]<br /> ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]<br /> ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]<br /> ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]<br /> ? tryinc_node_nr_active+0xe6/0x150<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]<br /> ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]<br /> ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]<br /> ? __pfx___raw_spin_lock_irqsave+0x10/0x10<br /> ? __pfx_do_vfs_ioctl+0x10/0x10<br /> ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0<br /> ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10<br /> ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]<br /> ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]<br /> __x64_sys_ioctl+0x138/0x1c0<br /> do_syscall_64+0x82/0x250<br /> ? fdget_pos+0x58/0x4c0<br /> ? ksys_write+0xf3/0x1c0<br /> ? __pfx_ksys_write+0x10/0x10<br /> ? do_syscall_64+0xc8/0x250<br /> ? __pfx_vm_mmap_pgoff+0x10/0x10<br /> ? fget+0x173/0x230<br /> ? fput+0x2a/0x80<br /> ? ksys_mmap_pgoff+0x224/0x4c0<br /> ? do_syscall_64+0xc8/0x250<br /> ? do_user_addr_fault+0x37b/0xfe0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> ? clear_bhb_loop+0x50/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix peer HE MCS assignment<br /> <br /> In ath11k_wmi_send_peer_assoc_cmd(), peer&amp;#39;s transmit MCS is sent to<br /> firmware as receive MCS while peer&amp;#39;s receive MCS sent as transmit MCS,<br /> which goes against firmwire&amp;#39;s definition.<br /> <br /> While connecting to a misbehaved AP that advertises 0xffff (meaning not<br /> supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff<br /> is assigned to he_mcs-&gt;rx_mcs_set field.<br /> <br /> Ext Tag: HE Capabilities<br /> [...]<br /> Supported HE-MCS and NSS Set<br /> [...]<br /> Rx and Tx MCS Maps 160 MHz<br /> [...]<br /> Tx HE-MCS Map 160 MHz: 0xffff<br /> <br /> Swap the assignment to fix this issue.<br /> <br /> As the HE rate control mask is meant to limit our own transmit MCS, it<br /> needs to go via he_mcs-&gt;rx_mcs_set field. With the aforementioned swapping<br /> done, change is needed as well to apply it to the peer&amp;#39;s receive MCS.<br /> <br /> Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41<br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1