Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: use RCU in ip6_xmit()<br /> <br /> Use RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent<br /> possible UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctx<br /> <br /> In __blk_mq_update_nr_hw_queues() the return value of<br /> blk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctx<br /> fails, later changing the number of hw_queues or removing disk will<br /> trigger the following warning:<br /> <br /> kernfs: can not remove &amp;#39;nr_tags&amp;#39;, no directory<br /> WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160<br /> Call Trace:<br /> remove_files.isra.1+0x38/0xb0<br /> sysfs_remove_group+0x4d/0x100<br /> sysfs_remove_groups+0x31/0x60<br /> __kobject_del+0x23/0xf0<br /> kobject_del+0x17/0x40<br /> blk_mq_unregister_hctx+0x5d/0x80<br /> blk_mq_sysfs_unregister_hctxs+0x94/0xd0<br /> blk_mq_update_nr_hw_queues+0x124/0x760<br /> nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]<br /> nullb_device_submit_queues_store+0x92/0x120 [null_blk]<br /> <br /> kobjct_del() was called unconditionally even if sysfs creation failed.<br /> Fix it by checkig the kobject creation statusbefore deleting it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC<br /> <br /> The referenced commit introduced exception handlers on user-space memory<br /> references in copy_from_user and copy_to_user. These handlers return from<br /> the respective function and calculate the remaining bytes left to copy<br /> using the current register contents. This commit fixes a couple of bad<br /> calculations. This will fix the return value of copy_from_user and<br /> copy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: ks-sa - fix division by zero in ks_sa_rng_init<br /> <br /> Fix division by zero in ks_sa_rng_init caused by missing clock<br /> pointer initialization. The clk_get_rate() call is performed on<br /> an uninitialized clk pointer, resulting in division by zero when<br /> calculating delay values.<br /> <br /> Add clock initialization code before using the clock.<br /> <br /> <br /> drivers/char/hw_random/ks-sa-rng.c | 7 +++++++<br /> 1 file changed, 7 insertions(+)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: fix null pointer dereference on zero-length checksum<br /> <br /> In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes<br /> checksum.data to be set to NULL. This triggers a NPD when accessing<br /> checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that<br /> the value of checksum.len is not less than XDR_UNIT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix data race in CPU latency PM QoS request handling<br /> <br /> The cpu_latency_qos_add/remove/update_request interfaces lack internal<br /> synchronization by design, requiring the caller to ensure thread safety.<br /> The current implementation relies on the &amp;#39;pm_qos_enabled&amp;#39; flag, which is<br /> insufficient to prevent concurrent access and cannot serve as a proper<br /> synchronization mechanism. This has led to data races and list<br /> corruption issues.<br /> <br /> A typical race condition call trace is:<br /> <br /> [Thread A]<br /> ufshcd_pm_qos_exit()<br /> --&gt; cpu_latency_qos_remove_request()<br /> --&gt; cpu_latency_qos_apply();<br /> --&gt; pm_qos_update_target()<br /> --&gt; plist_del memset(req, 0, sizeof(*req));<br /> --&gt; hba-&gt;pm_qos_enabled = false;<br /> <br /> [Thread B]<br /> ufshcd_devfreq_target<br /> --&gt; ufshcd_devfreq_scale<br /> --&gt; ufshcd_scale_clks<br /> --&gt; ufshcd_pm_qos_update cpu_latency_qos_update_request<br /> --&gt; pm_qos_update_target<br /> --&gt; plist_del

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix peer lookup in ath12k_dp_mon_rx_deliver_msdu()<br /> <br /> In ath12k_dp_mon_rx_deliver_msdu(), peer lookup fails because<br /> rxcb-&gt;peer_id is not updated with a valid value. This is expected<br /> in monitor mode, where RX frames bypass the regular RX<br /> descriptor path that typically sets rxcb-&gt;peer_id.<br /> As a result, the peer is NULL, and link_id and link_valid fields<br /> in the RX status are not populated. This leads to a WARN_ON in<br /> mac80211 when it receives data frame from an associated station<br /> with invalid link_id.<br /> <br /> Fix this potential issue by using ppduinfo-&gt;peer_id, which holds<br /> the correct peer id for the received frame. This ensures that the<br /> peer is correctly found and the associated link metadata is updated<br /> accordingly.<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 /> ASoC: Intel: sof_sdw: Prevent jump to NULL add_sidecar callback<br /> <br /> In create_sdw_dailink() check that sof_end-&gt;codec_info-&gt;add_sidecar<br /> is not NULL before calling it.<br /> <br /> The original code assumed that if include_sidecar is true, the codec<br /> on that link has an add_sidecar callback. But there could be other<br /> codecs on the same link that do not have an add_sidecar callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable().<br /> <br /> mptcp_active_enable() is called from subflow_finish_connect(),<br /> which is icsk-&gt;icsk_af_ops-&gt;sk_rx_dst_set() and it&amp;#39;s not always<br /> under RCU.<br /> <br /> Using sk_dst_get(sk)-&gt;dev could trigger UAF.<br /> <br /> Let&amp;#39;s use __sk_dst_get() and dst_dev_rcu().

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: pci_endpoint_test: Fix array underflow in pci_endpoint_test_ioctl()<br /> <br /> Commit eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case")<br /> added NO_BAR (-1) to the pci_barno enum which, in practical terms,<br /> changes the enum from an unsigned int to a signed int. If the user<br /> passes a negative number in pci_endpoint_test_ioctl() then it results in<br /> an array underflow in pci_endpoint_test_bar().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod<br /> <br /> Since commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when<br /> device is gone") UBSAN reports:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17<br /> index 28 is out of range for type &amp;#39;pm8001_phy [16]&amp;#39;<br /> <br /> on rmmod when using an expander.<br /> <br /> For a direct attached device, attached_phy contains the local phy id.<br /> For a device behind an expander, attached_phy contains the remote phy<br /> id, not the local phy id.<br /> <br /> I.e. while pm8001_ha will have pm8001_ha-&gt;chip-&gt;n_phy local phys, for a<br /> device behind an expander, attached_phy can be much larger than<br /> pm8001_ha-&gt;chip-&gt;n_phy (depending on the amount of phys of the<br /> expander).<br /> <br /> E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of the<br /> ports has an expander connected. The expander has 31 phys with phy ids<br /> 0-30.<br /> <br /> The pm8001_ha-&gt;phy array only contains the phys of the HBA. It does not<br /> contain the phys of the expander. Thus, it is wrong to use attached_phy<br /> to index the pm8001_ha-&gt;phy array for a device behind an expander.<br /> <br /> Thus, we can only clear phy_attached for devices that are directly<br /> attached.