Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend<br /> <br /> Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")<br /> removed most users of the platform device driver data from the<br /> qcom-qmp-usb driver, but mistakenly also removed the initialisation<br /> despite the data still being used in the runtime PM callbacks. This bug<br /> was later reproduced when the driver was copied to create the qmp-usbc<br /> driver.<br /> <br /> Restore the driver data initialisation at probe to avoid a NULL-pointer<br /> dereference on runtime suspend.<br /> <br /> Apparently no one uses runtime PM, which currently needs to be enabled<br /> manually through sysfs, with these drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend<br /> <br /> Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")<br /> removed most users of the platform device driver data from the<br /> qcom-qmp-usb driver, but mistakenly also removed the initialisation<br /> despite the data still being used in the runtime PM callbacks. This bug<br /> was later reproduced when the driver was copied to create the<br /> qmp-usb-legacy driver.<br /> <br /> Restore the driver data initialisation at probe to avoid a NULL-pointer<br /> dereference on runtime suspend.<br /> <br /> Apparently no one uses runtime PM, which currently needs to be enabled<br /> manually through sysfs, with these drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom: qmp-usb: fix NULL-deref on runtime suspend<br /> <br /> Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")<br /> removed most users of the platform device driver data, but mistakenly<br /> also removed the initialisation despite the data still being used in the<br /> runtime PM callbacks.<br /> <br /> Restore the driver data initialisation at probe to avoid a NULL-pointer<br /> dereference on runtime suspend.<br /> <br /> Apparently no one uses runtime PM, which currently needs to be enabled<br /> manually through sysfs, with this driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Initialize struct nfsd4_copy earlier<br /> <br /> Ensure the refcount and async_copies fields are initialized early.<br /> cleanup_async_copy() will reference these fields if an error occurs<br /> in nfsd4_copy(). If they are not correctly initialized, at the very<br /> least, a refcount underflow occurs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()<br /> <br /> In the ad7124_write_raw() function, parameter val can potentially<br /> be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()<br /> is called within ad7124_set_channel_odr(). The ad7124_write_raw()<br /> function is invoked through the sequence: iio_write_channel_raw() -&gt;<br /> iio_write_channel_attribute() -&gt; iio_channel_write(), with no checks<br /> in place to ensure val is non-zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()<br /> <br /> In the ad9832_write_frequency() function, clk_get_rate() might return 0.<br /> This can lead to a division by zero when calling ad9832_calc_freqreg().<br /> The check if (fout &gt; (clk_get_rate(st-&gt;mclk) / 2)) does not protect<br /> against the case when fout is 0. The ad9832_write_frequency() function<br /> is called from ad9832_write(), and fout is derived from a text buffer,<br /> which can contain any value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlegacy: Clear stale interrupts before resuming device<br /> <br /> iwl4965 fails upon resume from hibernation on my laptop. The reason<br /> seems to be a stale interrupt which isn&amp;#39;t being cleared out before<br /> interrupts are enabled. We end up with a race beween the resume<br /> trying to bring things back up, and the restart work (queued form<br /> the interrupt handler) trying to bring things down. Eventually<br /> the whole thing blows up.<br /> <br /> Fix the problem by clearing out any stale interrupts before<br /> interrupts get enabled during resume.<br /> <br /> Here&amp;#39;s a debug log of the indicent:<br /> [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000<br /> [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000<br /> [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.<br /> [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload<br /> [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282<br /> [ 12.052207] ieee80211 phy0: il4965_mac_start enter<br /> [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff<br /> [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready<br /> [ 12.052324] ieee80211 phy0: il_apm_init Init card&amp;#39;s basic functions<br /> [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S<br /> [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm<br /> [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm<br /> [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK<br /> [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations<br /> [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up<br /> [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.<br /> [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down<br /> [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout<br /> [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort<br /> [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver<br /> [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared<br /> [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state<br /> [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master<br /> [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.<br /> [ 12.058869] ieee80211 phy0: Hardware restart was requested<br /> [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.<br /> [ 16.132303] ------------[ cut here ]------------<br /> [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.<br /> [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]<br /> [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev<br /> [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143<br /> [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010<br /> [ 16.132463] Workqueue: async async_run_entry_fn<br /> [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]<br /> [ 16.132501] Code: da 02 00 0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: clear wdev-&gt;cqm_config pointer on free<br /> <br /> When we free wdev-&gt;cqm_config when unregistering, we also<br /> need to clear out the pointer since the same wdev/netdev<br /> may get re-registered in another network namespace, then<br /> destroyed later, running this code again, which results in<br /> a double-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: Fix memory leak in management tx<br /> <br /> In the current logic, memory is allocated for storing the MSDU context<br /> during management packet TX but this memory is not being freed during<br /> management TX completion. Similar leaks are seen in the management TX<br /> cleanup logic.<br /> <br /> Kmemleak reports this problem as below,<br /> <br /> unreferenced object 0xffffff80b64ed250 (size 16):<br /> comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)<br /> hex dump (first 16 bytes):<br /> 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t......<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e4/0x2d8<br /> [] kmalloc_trace+0x48/0x110<br /> [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]<br /> [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]<br /> [] process_scheduled_works+0x1ac/0x400<br /> [] worker_thread+0x208/0x328<br /> [] kthread+0x100/0x1c0<br /> [] ret_from_fork+0x10/0x20<br /> <br /> Free the memory during completion and cleanup to fix the leak.<br /> <br /> Protect the mgmt_pending_tx idr_remove() operation in<br /> ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-&gt;data_lock similar to<br /> other instances.<br /> <br /> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower<br /> <br /> Avoid potentially crashing in the driver because of uninitialized private data

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Additional check in ntfs_file_release

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Fix use-after-free, permit out-of-order decoder shutdown<br /> <br /> In support of investigating an initialization failure report [1],<br /> cxl_test was updated to register mock memory-devices after the mock<br /> root-port/bus device had been registered. That led to cxl_test crashing<br /> with a use-after-free bug with the following signature:<br /> <br /> cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1<br /> cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1<br /> cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0<br /> 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1<br /> [..]<br /> cxld_unregister: cxl decoder14.0:<br /> cxl_region_decode_reset: cxl_region region3:<br /> mock_decoder_reset: cxl_port port3: decoder3.0 reset<br /> 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1<br /> cxl_endpoint_decoder_release: cxl decoder14.0:<br /> [..]<br /> cxld_unregister: cxl decoder7.0:<br /> 3) cxl_region_decode_reset: cxl_region region3:<br /> Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI<br /> [..]<br /> RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> cxl_region_decode_reset+0x69/0x190 [cxl_core]<br /> cxl_region_detach+0xe8/0x210 [cxl_core]<br /> cxl_decoder_kill_region+0x27/0x40 [cxl_core]<br /> cxld_unregister+0x5d/0x60 [cxl_core]<br /> <br /> At 1) a region has been established with 2 endpoint decoders (7.0 and<br /> 14.0). Those endpoints share a common switch-decoder in the topology<br /> (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits<br /> the "out of order reset case" in the switch decoder. The effect though<br /> is that region3 cleanup is aborted leaving it in-tact and<br /> referencing decoder14.0. At 3) the second attempt to teardown region3<br /> trips over the stale decoder14.0 object which has long since been<br /> deleted.<br /> <br /> The fix here is to recognize that the CXL specification places no<br /> mandate on in-order shutdown of switch-decoders, the driver enforces<br /> in-order allocation, and hardware enforces in-order commit. So, rather<br /> than fail and leave objects dangling, always remove them.<br /> <br /> In support of making cxl_region_decode_reset() always succeed,<br /> cxl_region_invalidate_memregion() failures are turned into warnings.<br /> Crashing the kernel is ok there since system integrity is at risk if<br /> caches cannot be managed around physical address mutation events like<br /> CXL region destruction.<br /> <br /> A new device_for_each_child_reverse_from() is added to cleanup<br /> port-&gt;commit_end after all dependent decoders have been disabled. In<br /> other words if decoders are allocated 0-&gt;1-&gt;2 and disabled 1-&gt;2-&gt;0 then<br /> port-&gt;commit_end only decrements from 2 after 2 has been disabled, and<br /> it decrements all the way to zero since 1 was disabled previously.